Celestin Apprentice 5/Apprentice-Release5.iso/Information/THINK C Digest/1991/91-07

Text File | 1995-12-31 | 121KB | 3,326 lines

Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: System 7 Prototypes/Header Files
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 1 Jul 91 13:13:22 GMT

>The next major
>release of THINK C will fully support development under System 7, and
>it will contain headers and libraries similar to those that we're
>currently distributing.

So, does this mean a Sys7.0-aware THINK Class Library? And will it be fully
upward-compatible with the current TCL (i.e. I can port my TCL-derived
subclasses immediately)?

        Nick.











Path: ucivax!gateway
From: [e-mail] ("Mr. Neb")
Subject: Printing a file...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 12
Date: 1 Jul 91 14:16:21 GMT


    This will just take a moment.  I have created a specific file
structure that I would like to print reports on based on this file
structure.  Since this is the first time that I have tried to program
the printing of a record, I would like some advice on the best way to
go about it.

    Thanks in advance,

    David Nebinger

    [e-mail]










Path: ucivax!gateway
From: [e-mail] (Lars Petrus)
Subject: BUG in ANSI-881 !!
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 33
Date: 3 Jul 91 01:45:07 GMT

   Converting my project to 68881 math, I achieved a major speed improvement
and a few bugs. I think I have narrowed them down to a Real Bug in the
atan2() implementation in ANSI-881. It looks like this:

double atan2(y, x)
register double y, x;
{
    register double z;

    DomainCheck(x == 0 && y == 0, Zero);
    z = _atan(y / x);
    if (x < 0) {
        if (y < 0)
            z -= Pi;
        else
            z += Pi;
    }
    return(z);
}


   This looks perfect, but it fails when (x == -0). That changes the sign
of y/x, but does not trigger the (x < 0) test, giving a result of the
opposite of the correct angle!


   How do I make my program work? The atan2() implementation in ANSI looks
sound. Could I just copy the source code?



"Madness is the first sign of dandruff" |   Email:   [e-mail]
   - Dr Winston O'Boogie                |   Reality: Lars Petrus, Solna, Sweden










Path: ucivax!gateway
From: [e-mail] (Chris McNeil)
Subject: Cdev Crashes
Message-ID: <[e-mail]>
X-Mailer: QuickMail/SMTP interface.
Newsgroups: fa.think-c
Lines: 156
Date: 3 Jul 91 13:09:51 GMT

Hi, I wrote a cdev base on the sample cdev that comes with think C.
When I call the following routine when item hit = 3 it works on my SE/30, and
my MacII, but my SE freezes solid. Pete Resnick tells me that I'm writing over
low mem but I'm just begining to program on the mac and I can't find the
problem. Here is the code. Can anyone give me any hints about what is obviously
wrong.
This is part of NetCookie ( a mac cookie client). This program will be free and
posted on the info-mac archives if I can get this part to work( the init part
works fine).  Also anyone helping me will recieve due credit in the about
NetCookie dialog.

Chris McNeil
[e-mail]

void cookie()
{
    int errCode;
    WindowPtr MyWindow;
    GrafPort saveport;
    int Done;
    EventRecord myEvent;
    int charcode;
    int index;
    Rect windowbounds;
    int lines;
    Str255 buf;
    int LookupAddr();
    unsigned long refnum;
    unsigned long rbuffer[rbuffer_len];
    unsigned long ipaddr;
        struct {
        wdsEntry Buffer;
        short Terminator;
    } myData = {{0,0},0};

    char cookieStr[2048];    /* buffer for quote returned from cookie server */
     UDPiopb CookiePB;

    /* Get the server name that the user entered in the cdev */

     editrec=TEGetText(hTE);
     GetIText((Handle)editrec,buf);
    PtoCstr((char *)buf);

/* Look up the address */

        errCode=LookupAddr((char *)buf);
        refnum=pb.ioParam.ioRefNum;
        if (errCode != 0) {
         CkieAlert();        /* if lookup of name fails post an alert */
        }
   else {

     ipaddr=serverInfo.addr[0];    /* use the first address returned */

    /* Create an UPB stream */

    CookiePB.csCode=UDPCreate;
    CookiePB.ioCRefNum=refnum;
    CookiePB.csParam.create.rcvBuff=(Ptr)&rbuffer;
    CookiePB.csParam.create.rcvBuffLen=rbuffer_len;
    CookiePB.csParam.create.notifyProc=0L;
    CookiePB.csParam.create.localPort=0;
    CookiePB.csParam.create.userDataPtr=0L;
    errCode=PBControl(&CookiePB, false);

    if ( errCode == noErr ) {

    /*send an UDP  packet to the cookie server */

        CookiePB.csCode=UDPWrite;
        CookiePB.csParam.send.remoteHost=ipaddr;
        CookiePB.csParam.send.remotePort=17;             /* cookie server port */
        CookiePB.csParam.send.wdsPtr=(Ptr)&myData;  /* send an UDP datagram */
        CookiePB.csParam.send.checkSum=0;
        CookiePB.csParam.send.userDataPtr=0L;
        errCode=PBControl(&CookiePB, false);

    }
    /* listen for a quote back from the server    */

    if ( errCode == noErr ) {

        CookiePB.csCode=UDPRead;
        CookiePB.csParam.receive.timeOut=ckie.cookietout;
        CookiePB.csParam.receive.secondTimeStamp=0;
        CookiePB.csParam.receive.userDataPtr=0L;
        errCode=PBControl(&CookiePB, false);
        if (errCode != noErr) {
        alertact=1;
        NoteAlert(-4065,0L);      /* Alert if error */
        alertact=0;
        }

        }

    if ( errCode == noErr ) {

        /* Take the newlines out of the return quote */
        index=0;
        lines=0;
        while (index != CookiePB.csParam.receive.rcvBuffLen){
        cookieStr[index]=*CookiePB.csParam.receive.rcvBuff;
        if (*CookiePB.csParam.receive.rcvBuff == '\n') {
        cookieStr[index]='\r';  /* Put in a return */
        lines++;
        }
        index++;
        *CookiePB.csParam.receive.rcvBuff++;
        }
        cookieStr[index]='\0'; /* Terminate the string */

        /* Convert to Pascal string  */

        CtoPstr((char *)cookieStr);

        /* Calculate the size of the window needed for the cookie reponse */

        windowbounds.top=30;
        windowbounds.left=8;
        windowbounds.right=508;
        windowbounds.bottom=(((16* lines)+windowbounds.top));
        GetPort(&saveport);

        MyWindow=NewWindow(0L,&windowbounds,"",1,2,-1L,1,1);
        SetPort(MyWindow);


        /* Write the cookie to the window    */

         ShowWindow(MyWindow);
        TextBox((Ptr)&cookieStr[1],index,(&(*MyWindow).portRect),0);

    /* Wait until mouse down to kill window */

    for(;;){
             GetNextEvent(everyEvent, &myEvent);
             if (myEvent.what==mouseDown ) break;

               }


    DisposeWindow(MyWindow);
    SetPort(&saveport);


}
/* Release the stream when done */
     CookiePB.csCode=UDPRelease;
     errCode=PBControl(&CookiePB, false);

}

}












Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: TC4.0.5, Sys7.0 cosmetic bug
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 3 Jul 91 16:16:01 GMT

Are you supposed to be able to switch THINK C into the background while
it's compiling something? Certainly seems possible under Sys7.0, which is
nice, except that the line number counts always get drawn directly onto the
screen, regardless of whose window(s) happen to be there.

        Nick.











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: TC4.0.5, Sys7.0 cosmetic bug
Message-ID: <[e-mail]>
In-Reply-To: Nick Rothwell's message of 3 Jul 91 16:16:01 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 3 Jul 91 18:54:28 GMT

   Are you supposed to be able to switch THINK C into the background
   while it's compiling something? Certainly seems possible under
   Sys7.0, which is nice, except that the line number counts always
   get drawn directly onto the screen, regardless of whose window(s)
   happen to be there.

It's a bug, not a feature :-(.

    -phil










Path: ucivax!gateway
From: [e-mail]
Subject: a few "big" questions
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 36
Date: 4 Jul 91 05:48:55 GMT



hi,

though this probably belongs more in comp.sys.mac.programmer, i can
never keep up with the traffic there.  so i'm posting these questions
here, even though their relevance to the think c environment is
somewhat questionable...

here goes...any insight would be *mucho* welcome!


(1) how do people store pointers?  that is, how can i maintain *references*
to other objects when i store an object, either on the scrap or in a
file?  this is major design issue for me, though there's probably some
simple solution that i've overlooked.

for example, object A and object B both need to be stored. object A has
a reference to object B to link the two.  how can this relationship be
preserved through the save/restore process?

(2) how can i manage huge resources?  these are resources which are likely
to be much too big to fit in ram.  i'd like to be able to do what i'd do
if the information were in a data fork:  keep a filePos handy, read in
a bite-size chunk, play with it in ram, write it back to the same spot in
the file, and advance the filePos.  (aside: i can't use the data fork for
this application because it's possible that there will be a dozen independent
entities needed. this creates unsightly temp-files and could run into the
max-num-of-files-open limit.)


the proverbial "thanks-in-advance", with the hope that they'll be
well-deserved...;)

:jeff bellsey
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: TC4.0.5, Sys7.0 cosmetic bug
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 4 Jul 91 09:48:49 GMT

>It's a bug, not a feature :-(.

Fair enough. The question still stands, though: is the bug the fact that I
am able to compile in the background, or is it just the bad display when I
do? I can't say I find background compilation that useful (at several
hundred lines per sec. it hardly seems worth it) but it's silly to disallow
it. If it *is* allowed, though, the compiler should at least call
GetNextEvent() more often, get rid of its modal dialog window, and use the
Notification Manager for errors/completion.

        Nick.











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: TC4.0.5, Sys7.0 cosmetic bug
Message-ID: <[e-mail]>
In-Reply-To: Nick Rothwell's message of 4 Jul 91 09:48:49 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 4 Jul 91 21:25:02 GMT

   >It's a bug, not a feature :-(.

   Fair enough. The question still stands, though: is the bug the fact
   that I am able to compile in the background, or is it just the bad
   display when I do?

Yes, it's a bug that THINK C lets you switch it out when it's
compiling.  THINK C isn't designed to be run in the background,
although background compilation is an idea that we're considering.
The main problem is that the THINK C compiler is coded specifically
for speed, and recoding it for both speed and backgrounding would
probably not produce satisfactory results.  It certainly is an
interesting idea, though.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Jamer)
Subject: My first foray
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 5 Jul 91 20:30:14 GMT

OK,

I'm trying to learn this think c business, so I bought the Mac Programming
Primer.  Like everyone else, I did the Hello World Program, and thought I was
off on the road.  But, I typed in the Hello2 program (in the book), and found
a bug that I have no idea what to do.  I've gone through to check my typing,
but every time I try to precompile, or check syntax, or run, or anything else,
I get the message "Can't open #include'd file".  Now I know very little about
C, but I do know that there are no #include files called in the Hello2 source.
Can anyone help an absolute beginner?

Later,
Jamer.










Path: ucivax!gateway
From: [e-mail] (Mark Alldritt)
Subject: Editor window sizes
Message-ID: <9107051250*[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 5 Jul 91 20:35:58 GMT

Hello,

    I'm looking for a way of altering the default size of THINK-C Editor
windows.  Specifically, I want the windows to be narrower on my two-page
display.  The default window size is too wide to have two files displayed
side-by-side which forces me to resize every window I open.  This is not a
show-stopper, just a time waster.

    Is there a resource within THINK-C that governs this?

Thanks in advance
-Mark










Path: ucivax!gateway
From: [e-mail] ("Richard E Beecher (907")
Subject: Attaching a document when using LaunchApplication()
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 5 Jul 91 22:26:31 GMT


I am trying to write an application that will launch an application along
with an associated document using the new toolbox routine LaunchApplication.
I understand how to launch the application, but I don't know how to attach
a document to the launch parameter block. Has anyone out there done this?
Any help would be greatly appreciated.  Thanks in advance,

Richard Beecher
[e-mail]  (Arco Alaska, Inc.)










Path: ucivax!gateway
From: [e-mail] (Barry L Wolman)
Subject: CDEFs in Desk Accessories
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 58
Date: 6 Jul 91 04:01:14 GMT

I'm having some problems trying to use two custom CDEFs in a DA
written in Think C.  The CDEFs have IDs -16000 and -15999 so they can
be owned by the DA and be moved with the other resources by Font/DA
Mover.  This means the CDEFs can't be referenced from the controls
that need to use them.  My plan to get around this problem is to store
the handle to the CDEF in the controls that use them.

First, I load the CDEF resources by name and lock the handles

    if ((Hpopup = GetNamedResource('CDEF',POPUP_NAME)) == nil) return(0);
    if ((Hdefault = GetNamedResource('CDEF',DEFAULT_NAME)) == nil) return(0);

    HLock(Hpopup);
    HLock(Hdefault);

My  code that displays the startup dialog is

int startup_dialog()
    {
    DialogPtr    startup_dp;
    ...

    if ((startup_dp = GetNewDialog(STARTUPBOX, 0L, (WindowPtr)-1)) == nil)
        return FALSE;

    if (!GetCustomControl(START_CONTROL,startup_dp,Hdefault,START_VARIANT)) {
        DisposDialog(startup_dp);
        return FALSE;
        }

    ...
    }

GetCustomControl is a utility function I wrote to load a control and
set the contrlDefProc; its code is

int GetCustomControl(short id, WindowPtr wptr,Handle Hcdef,short variant)
    {
    ControlHandle ch;

    if ((ch = GetNewControl(id,wptr)) == nil) return FALSE;
    (*ch) -> contrlDefProc = (Handle)(((long)Hcdef & 0xffffff) | (variant <<
24));
    return TRUE;
    }

I've used breakpoints to verify that the contrl record is modified
properly.  Yet, when the dialog window appears, I get a bus error
inside the CDEF.  If I remove the assignment to contrlDefProc and
rerun, the bus error disappears (although, obviously, the control
doesn't use the desired CDEF).

Perhaps I'm too close to the trees to see the forest.  What am I
doing wrong?

In case it makes any differences, I'm running 6.0.5 on a 8MB IIci.

Thanks, Barry










Path: ucivax!gateway
From: [e-mail]
Subject: thanks, and more!
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 31
Date: 6 Jul 91 04:44:58 GMT


hi,

thanks to all who responded about storing references (the solution,
for those who may encounter the same problem: keep some sort of
hash table with an index to every pointer referenced, then replace
references with indexes).

however, the responses about managing huge resources were not entirely
usable.  the suggestions revolved around new toolbox calls
"ReadPartialResource" and "WritePartialResource".  these (unfortunately)
sound like *exactly* what i need, if it weren't for the fact that
they're not yet implemented in think c.  could i use them anyway, if
i want my application to run under sys6?

i suppose i was looking for some insight into finagling with the
resource map, using PB-calls on the resource fork.  if anyone has
anything helpful here, i would *much* appreciate it...

a new question: i vaguely remember a class someone posted
which allowed you to create classes based on a single integer
without "switching" the int.  ie, by using some preprocessor
directive, you could take an int and create a class.  for example:
    if i=1, create/init CJoe
    if i=2, create/init CSpike
    if i=3, create/init CCrusher

is this possible??

:jeff bellsey
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Jamer)
Subject: Me again!
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 6 Jul 91 06:01:33 GMT

Hi,

Thanks to everyone who gave suggestions as to what to do with the #include
problem.  I changed the Option, but have now run into an Invalid Declaration at
the following:

WindowPtr       gHelloWindow

This comes right after the #define's.  Any ideas?

Thanks,
Jamer.










Path: ucivax!orion.oac.uci.edu!nntpsrv
From: [e-mail] (Bill Dugan)
Subject: Debugger crashes when I try looking at rect.topLeft
Nntp-Posting-Host: teri.bio.uci.edu
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Organization: University of California, Irvine
Lines: 15
Date: 6 Jul 91 08:56:12 GMT
Distribution: fa

When I have a Rect called "rect" and I use the Think C debugger to look at

rect.topLeft

the debugger crashes into Macsbug!  I had a problem defining rect.topLeft
as a legitimate structure, also; when I try to access rect.topLeft in my
code, the compiler tells me that topLeft is an unknown struct/union member.
Is there something wrong with my setup?  Do I have a problem with my
libraries?  Or is this actually a bug?

I'm running THINK C 4.0.5 on a Mac Plus with System 7, 4 megs of RAM.
I am using the standard MacHeaders.

bill











Path: ucivax!gateway
From: [e-mail] ("Michael J. Tarr")
Subject: removal from list
Full-Name: "Michael J. Tarr"
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 4
Date: 6 Jul 91 13:32:28 GMT


Please remove [e-mail] from the think-c mailing list.












Path: ucivax!gateway
From: [e-mail] (Tsuyoshi Motegi)
Subject: Removal from List
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 3
Date: 6 Jul 91 17:13:15 GMT

Please remove [e-mail] from the mailing list.

                        --tm










Path: ucivax!gateway
From: [e-mail] (Ernie Oporto 867-5212)
Subject: Help with Updates and structs (long)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 131
Date: 6 Jul 91 19:53:55 GMT

    My problem is this.  On the advice of some people, I have
tried to make a structure to hold the information for windows and
associated picture id's in, so as to avoid having a long list of
if-then testing.  I seem to be having major problems in keeping
all of the pointers straight, as I hardly understand them.  If
anyone can look at this code and tell me whats wrong with my struct
and why the program quits for no reason, I would greatly appreciate it.
(Please?!?!?!  This is driving me insane!)

/*** PICTWindow structure ***/
typedef struct
{
    WindowPtr    newWindow;
    short        pictId;
}    PICTWindow;


PICTWindow        gSplashWindow,gHeightWindow;
            /*** and other globals ***/

/***main***/
main()
{
    ...
    SplashInit();
    MainLoop();
        /*** this calls HandleEvent which calls
        HandleFileChoice when the cursor is in MenuBar***/
    ...
}



(I have a problem in SplashInit where the program just quits on the
DisposeWindow call.)



/*** SplashInit ***/
SplashInit()
{
    CreateWindow(BASE_RES_ID,gSplashWindow);
    while(!Button());
    DisposeWindow(gSplashWindow.newWindow);
}


/*** HandleFileChoice ***/
HandleFileChoice(theItem)
int        theItem;
{
    WindowPtr    whichWindow;

    switch(theItem)
    {
        case HEIGHT_ITEM:/*** these menu selections make
                            the Height window appear ***/
            CreateWindow(BASE_RES_ID+2,gHeightWindow);
            break;
        case ....
    }
}


/*** CreateWindow ***/
CreateWindow(theResId,createWind)
short        theResId;
PICTWindow    *createWind;
{
    WindowPtr    theWind;

    theWind = GetNewWindow(theResId,NIL_POINTER,MOVE_TO_FRONT);
    createWind->pictId = theResId;
    createWind->newWindow = theWind;

    ShowWindow(createWind->newWindow);
    SetPort(createWind->newWindow);

    DrawMyPicture(createWind);
}

/*** DrawMyPicture ***/
DrawMyPicture(pictWindPtr)
PICTWindow        *pictWindPtr;
{
    Rect             myRect;
    PicHandle        thePicture;
    WindowPtr        theWindow;

    thePicture = GetPicture(pictWindPtr->pictId);
    theWindow = pictWindPtr->newWindow;

    myRect = theWindow->portRect;
    CenterPict(thePicture,&myRect);
    SetPort(theWindow);
    DrawPicture(thePicture,&myRect);
}

/*** HandleEvent ***/
HandleEvent()
{
    ...
    switch(gTheEvent.what)
    {
       ...
        case updateEvt:
            if(!IsDAWindow(theWindow))
            {
                GetPort(&oldPort);
                SetPort(theWindow);
                BeginUpdate(theWindow);
                DrawMyPicture(theWindow);
                EndUpdate(theWindow);
                SetPort(oldPort);
            }
            break;
    }
}




Ernie "SHOKK" Oporto();
{
      _____)           ______        _)       _)  [e-mail]
                                   __       __          Student
    ______    ______            ___      ___      Computer Laboratory
                                   __       __      Attendant of the
    (_______ _      _ ________ _     _) _     _)  PennState University
                                                  Center for Academic
}                                                      Computing










Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: Attaching a document when using LaunchApplication()
Message-ID: <[e-mail]>
In-Reply-To: Your message of 05 Jul 91 22:26:31 +0000.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 7 Jul 91 19:46:15 GMT

> I am trying to write an application that will launch an application along
> with an associated document using the new toolbox routine LaunchApplication.
> I understand how to launch the application, but I don't know how to attach
> a document to the launch parameter block.

Wouldn't the politically correct way to do this under System 7 be to
launch the application, then send it an










Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: Attaching a document when using LaunchApplication()
Message-ID: <[e-mail]>
In-Reply-To: Your message of 05 Jul 91 22:26:31 +0000.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 7 Jul 91 19:49:39 GMT

Sorry for inadvertently sending out an incomplete message.

I was going to suggest that the "correct" way to do this would be to
send the sub-application an Open Document Apple Event, but then I
realized that the sub-app would then have to be AppleEvent-aware,
which you probably can't guarantee.

Another option might be to send the appropriate events to the Finder
to get it to launch the application for you (and open the document).
I have a feeling that Apple probably prefers that method.

Unfortunately, I don't have any System 7 documentation handy at the
moment, so I can't be more specific.

-- Russell Finn
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Jamie McCarthy)
Subject: AppleEvents and the TCL
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 38
Date: 7 Jul 91 22:12:01 GMT

Has anyone experimented with including AppleEvents into the Think Class
Library?  Neither I nor my applications are system-7.0 savvy yet, so I'm
not sure what it would involve, but it would seem that a modification to
(or a subclass of) CSwitchboard would be appropriate.

From looking briefly at some sample code, it appears that there are
three major parts to the task:  (1) calling an initialization routine at
startup time, like so:

theOSErr = AEInstallEventHandler (kCoreEventClass, kAEQuitApplication,
    (EventHandlerProcPtr) HandleAEquit, 0, false);

(2) checking events to see if they're High-Level (CSwitchboard's job):

if (anEvent.what == kHighLevelEvent)
    (void) AEProcessAppleEvent (&anEvent);

and (3) implementing the handler itself:

static pascal void HandleAEquit (AppleEvent *quitAppleEvent,
    AppleEvent *reply, long handlerRefCon)
{
/* The quit AE has no parms, but check in case the client requires any */
    if (DoneRequiredParams (quitAppleEvent) == noErr)
        gQuitting = true;
}

Is this essentially all that needs to be done?  Has anyone done it
already?  Do I need to do these three steps for each AE I implement
('cos this only handles quit)?

The source code was taken from the GMonde example, off the Developers'
CD I believe.
--
 Jamie McCarthy                           [e-mail]
 Disclaimer: it's my responsibility iff they're my words.
 Alle diese Gleichnisse wollen eigentlich nur sagen, dass das Unfassbare
 unfassbar ist, und das haben wir gewusst.










Path: ucivax!gateway
From: [e-mail]
Subject: Re: Attaching a document when using LaunchApplication()
Message-ID: <[e-mail]>
In-Reply-To: Your message of "07 Jul 91 19:49:39 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 7 Jul 91 23:35:09 GMT

>I was going to suggest that the "correct" way to do this would be to
>send the sub-application an Open Document Apple Event, but then I
>realized that the sub-app would then have to be AppleEvent-aware,
>which you probably can't guarantee.

The receiving application does NOT have to be AppleEvent aware to
accept the open document event.  If the application is not AE aware,
the system will simulate an Open, and then the return from SFGetFile
just like MultiFinder has been doing for years.
  --dave koziol










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Debugger crashes when I try looking at rect.topLeft (THC 4.0.5)
Message-ID: <[e-mail]>
In-Reply-To: Bill Dugan's message of 6 Jul 91 08:56:12 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 48
Date: 8 Jul 91 00:28:18 GMT

   When I have a Rect called "rect" and I use the Think C debugger to
   look at

   rect.topLeft

   the debugger crashes into Macsbug!  I had a problem defining
   rect.topLeft as a legitimate structure, also; when I try to access
   rect.topLeft in my code, the compiler tells me that topLeft is an
   unknown struct/union member.  Is there something wrong with my
   setup?  Do I have a problem with my libraries?  Or is this actually
   a bug?

The bug is in the THINK C Debugger.  It gets really confused when you
try do display a macro, especially when the macro expects arguments
and you don't provide them.  "What macro?"  Well, THINK C implements
the topLeft and botRight fields of the QuickDraw Rect type as macros,
so you can say:

   topLeft(rect).h = botRight(rect).v * 10;    /* or whatever */

The reason that topLeft and botRight aren't implemented "correctly" as
they are in Pascal, is because that a C union requires the union's
field names for referencing, whereas Pascal can resolve unions
("variant records" in Pascal) without any extra names.  E.g., if you
had:

    typedef union {
        struct {
            short top, left, bottom, right
        } coords;
        struct {
            Point topLeft, botRight;
        } points;
    } Rect;

You'd have to say "rect.coords.top" or "rect.points.topLeft".  For a
bigger example of this problem, check out the PB structures in IM IV,
and their definitions in HFS.h.  Here unions are used, but it's much
less convenient in C than in Pascal.

MPW C does not define the macros (or fields) topLeft and botRight,
they're not implemented at all.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!orion.oac.uci.edu!teri.bio.uci.edu!bdugan
From: [e-mail] (Bill Dugan)
Subject: Re: Debugger crashes when I try looking at rect.topLeft (THC 4.0.5)
Nntp-Posting-Host: teri.bio.uci.edu
Message-ID: <[e-mail]>
Summary: Oh well.  Asi es la vida.
Newsgroups: fa.think-c
Organization: University of California, Irvine
Lines: 16
Date: 8 Jul 91 02:35:13 GMT
References: <[e-mail]>

In article <[e-mail]> [e-mail] (Phil Shapiro) writes:
>The reason that topLeft and botRight aren't implemented "correctly" as
>they are in Pascal, is because that a C union requires the union's
>field names for referencing, whereas Pascal can resolve unions
>("variant records" in Pascal) without any extra names.  E.g., if you
>had:
>
> [...]

Thanks for the information.  I just wanted to do as suggested in
IM's description of LocalToGlobal() to convert the coordinates of a Rect
by passing rect.topLeft and then rect.botRight.  I ended up manually
grabbing the window's position and using OffsetRect() instead.

bill











Path: ucivax!gateway
From: [e-mail] (Hans van der Meer)
Subject: mailing list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-Telex: 16460 facwn nl
Lines: 1
Date: 8 Jul 91 07:52:12 GMT
X-Phone: [phone]
X-Fax: [phone]
X-Organisation: Faculty of Mathematics & Computer Science
                University of Amsterdam
                Plantage Muidergracht 24
                NL-1018 TV Amsterdam
                The Netherlands

please remove [e-mail] from the think-c mailing list.










Path: ucivax!gateway
From: [e-mail] (Jamie McCarthy)
Subject: Re: topLeft & botRight
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Bill Dugan" at Jul 8, 91 2:35 am
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 15
Date: 8 Jul 91 12:20:44 GMT

Bill Dugan writes:
>
> Thanks for the information.  I just wanted to do as suggested in
> IM's description of LocalToGlobal() to convert the coordinates of a Rect
> by passing rect.topLeft and then rect.botRight.  I ended up manually
> grabbing the window's position and using OffsetRect() instead.

No need, I don't think.  Try:

LocalToGlobal(&topLeft(myRect));
LocalToGlobal(&botRight(myRect));
--
 Jamie McCarthy                           [e-mail]
 Disclaimer: it's my responsibility iff they're my words.
 There is an emerald here the size of a plover's egg!










Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: Attaching a document when using LaunchApplication()
Message-ID: <[e-mail]>
In-Reply-To: Your message of 07 Jul 91 23:35:09 +0000.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 10 Jul 91 01:01:40 GMT

> The receiving application does NOT have to be AppleEvent aware to
> accept the open document event.  If the application is not AE aware,
> the system will simulate an Open, and then the return from SFGetFile
> just like MultiFinder has been doing for years.

Well, this is certainly true when the Finder launches an application,
but we were talking about a sublaunch.  Is the Apple Event Manager
(or the Process Manager) responsible for translating an Open Document
event into the SFGetFile charade?

-- Russ










Path: ucivax!nagel
From: [e-mail] (Mark Nagel)
Subject: ADMIN: _Please_ use the right address...
Nntp-Posting-Host: buckaroo.ics.uci.edu
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Organization: UC Irvine Department of ICS
Lines: 15
Date: 10 Jul 91 05:54:40 GMT

Folks, if you need to be removed from the list or have other list
administrivia to relate, _please_ send it to:

    [e-mail]

and _not_ [e-mail].  The list has been pretty active
recently and most people dislike getting useless clutter in their
mailboxes.  Thanks!

Mark
--
Mark Nagel
UC Irvine Department of ICS   +----------------------------------------+
ARPA: [e-mail]       | N = 1 implies P = NP                   |
UUCP: ucbvax!ucivax!nagel     +----------------------------------------+










Path: ucivax!gateway
From: [e-mail] (opcode ranger)
Subject: How do you write a popup MDEF?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 31
Date: 10 Jul 91 23:49:41 GMT
X-Vmsmail-To: @THINKC

I'm trying to write an MDEF for a popup menu and am having some difficulties.
I've gotten my MDEF written and it works fine as a popup menu, but it doesn't
handle scrolling correctly (the scrolling it should do when it runs off the
edge of the screen).

IM-V says "On exit, the rectangle in which the pop-up menu is to appear is
returned in menuRect.  If the menu is so large that it scrolls, then the actual
top of the menu is returned in whichItem." What does this mean?  Does it mean
I've actually got to calculate the position of the top of the screen,
subtracting the menubar if I'm on the main screen, or not if I'm not (meaning
I've got to figure out which screen I'm on)?  Then I need to return the top of
menu as the top of the screen, subtracting the menubar if necessary?   (This
seems like a lot of trouble.  Shoudn't the menu manager be able to figure this
out?)

IM-V also says: "When a defproc draws a pop-up menu, its scrolling information
must be placed in the global variables TopMenuItem and AtMenuBottom".  So, I
put the top menu item number in TopMenuItem and put a 1 or 0 in AtMenuBottom if
the current menu item is the last in the menu?  Do I always do this, or only if
I'm actually scrolling?

Any help much appreciated!

Robert

============================================================================
= [e-mail] * generic disclaimer: * "Good tea.        =
=                             * all my opinions are *  Nice house."     =
=                                * mine                *  -Worf            =
============================================================================











Path: ucivax!gateway
From: [e-mail]
Subject: Re: How do you write a popup MDEF?
Message-ID: <[e-mail]>
In-Reply-To: Your message of "10 Jul 91 23:49:41 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 11 Jul 91 16:21:03 GMT

I don't have the answer to your questions but I do have a suggestion.
Lord of the Files (the current Developer CD), contains a folder called
"Menu Defproc 1.0.2" which is a MDEF written in MPW C.  It's pretty
easy follow, and really helped me with my MDEF.  (But I didn't have to
support scrolling or pop-ups....)
  --dave










Path: ucivax!gateway
From: [e-mail] (Raymond Beausoleil)
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 14 Jul 91 14:31:29 GMT

Is there any way around THINK C's 32k code segment limit for libraries? I've
been building a big "library" (using "Make") for about two years now, and it
has just grown beyond the 32k horizon. THINK C won't let me load it into any
projects, and it won't let me build a "real" library. Am I the only person
who finds this ridiculous in the age of 32-bit microprocessors?

Perhaps I am being naive, but the FORTRAN compilers that I have seen on the
Mac (which also have their own linkers) don't seem to need to segment code
at all. I asked a friend who is familiar with 68xxx assembly language, and
he claims that one can easily add two address registers in only slightly more
time than using the a-register plus displacement mode; this would allow
addressing throughout the entire memory space. The same approach could
be used in jumps, branches and subroutine calls (i.e., jsr). Fortran
doesn't seem to be very slowed down by this; in fact, it gives the best sieve
time of any language, I believe, and also gives very good whetstone
times (which involves lots of subroutine calls).

Will Apple's demand for 32-bit cleanliness allow bigger code segments in
THINK C? Am I completely missing the point here? Is my only possible solution
to break up the library into smaller segments?

Thanks in advance for your time and attention.

Regards,

Ray Beausoleil ([e-mail])










Path: ucivax!gateway
From: [e-mail] (Jamie McCarthy)
Subject: The THINK Reference
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 12
Date: 15 Jul 91 04:51:19 GMT

Any comments from users of the THINK(tm) Reference?  I generally prefer
paper to on-line reference, but it sounds pretty good.

"...THINK Reference integrates smoothly with both THINK C and THINK
Pascal" says the cover letter I got.  How smoothly?  Ideally, you could
hilite the name of a toolbox call, select a menu item, and have
information about it pop up in a window.  Or does it work differently?
--
 Jamie McCarthy            [e-mail] or [e-mail]
 Disclaimer:  it's my responsibility iff they're my words.
 There's not much point in wandering around out here, and you can't
 explore the cave without a lamp. So let's just call it a day.










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Segment size
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 15 Jul 91 11:14:36 GMT

>Is there any way around THINK C's 32k code segment limit for libraries? I've
>been building a big "library" (using "Make") for about two years now, and it
>has just grown beyond the 32k horizon. THINK C won't let me load it into any
>projects, and it won't let me build a "real" library. Am I the only person
>who finds this ridiculous in the age of 32-bit microprocessors?

No, I find it a little silly too. My understanding is that the limit is due
to the Resource Manager handling the CODE resources. Since resources can
only be 32K in size, code segments are similarly limited, even though
there's no real architectural limit to having the segments as large as you
want. Might not be a good idea to have huge code segments if you want to
start purging and reloading them, though.

I personally don't have a problem with this in practice. The TCL compiles
to three libraries (Core.1, Core.2, More Classes) which I include in every
project.

        Nick.











Path: ucivax!gateway
From: [e-mail] (Jamie McCarthy)
Subject: Re: Segment size
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Nick Rothwell" at Jul 15, 91 11:14 am
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 20
Date: 15 Jul 91 15:01:03 GMT

Nick Rothwell writes:
>
> No, I find it a little silly too. My understanding is that the limit is due
> to the Resource Manager handling the CODE resources. Since resources can
> only be 32K in size, code segments are similarly limited

Resources can be much larger. I've never found a limit; without IM
handy, I'd guess they could be the full 4 gigs.

The problem, I believe, is that some (ahem) compiler writers don't want
to handle the problem of >32K branches that arise when you have a >32K
code space. (No, wait, don't flame me if I'm wrong--maybe it _is_ a
MacOS restriction, I don't really know.  ;-)

I do know, however, that there's no good reason for limiting local
variables to 32K, which (last I checked) THINK C did.  Gr.
--
 Jamie McCarthy            [e-mail] or [e-mail]
 Disclaimer:  it's my responsibility iff they're my words.
 There is an emerald here the size of a plover's egg!










Path: ucivax!gateway
From: [e-mail] (Kent Borg)
Subject: Re: Segment size
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 15 Jul 91 15:56:54 GMT

Jamie McCarthy recently guessed that resources could be 4 gig.

I think that there is a 16-meg limit in there someplace.  I suspect
for the size of the whole resource fork (but this might have changed
with 7.0).  I can tell you that a friend of mine was once working on a
big Hypercard stack, and when sounds pushed it past 16 meg, things
broke, so they wrote an XCMD to open another file in which some of the
sounds were stored.

Another very real possiblity is that it was Hypercard 1.2.5 that was
choking.

--
Kent Borg                            internet: [e-mail]   AOL: kent borg
                                            H:[phone]  W:[phone]
About System 7.0: "More Mac-like than the old system."  - Kim Shelton, CSX










Path: ucivax!gateway
From: [e-mail] ("James F. Kennedy")
Subject: Re: segment size
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Posted-Date: Mon, 15 Jul 91 12:16:18 EDT
Newsgroups: fa.think-c
Lines: 36
Date: 15 Jul 91 16:16:43 GMT


Nick Rothwell writes:
>
> No, I find it a little silly too. My understanding is that the limit is due
> to the Resource Manager handling the CODE resources. Since resources can
> only be 32K in size, code segments are similarly limited

Jamie McCarthy writes:
>
>Resources can be much larger. I've never found a limit; without IM
>handy, I'd guess they could be the full 4 gigs.
>
>The problem, I believe, is that some (ahem) compiler writers don't want
>to handle the problem of >32K branches that arise when you have a >32K
>code space. (No, wait, don't flame me if I'm wrong--maybe it _is_ a
>MacOS restriction, I don't really know.  ;-)
>
>I do know, however, that there's no good reason for limiting local
>variables to 32K, which (last I checked) THINK C did.  Gr.

Hmmm..I seem to remember that in pre-system 7.0, code resources were limited
to 32K because of the inability for the Resource manager to handle
CODE resources larger than 32K.  I also seem to remember something about
the way in which the mac os handles relocatable code is also a limiting
factor.  Lord knows how it is in system 7.0 - one would think they fixed
this annoying problem (the mac is the only 32 bit system that I know
of restricted to 32K code segments).

 I do know that global data is limited to 32K because of the A5_world
scheme....maybe this has something to do with code segments too...I'll
have to go back and take a look.

            James
--
James F. Kennedy        "Don't eat it if you don't like it."
[e-mail]        "This is MY opinion:)"










Path: ucivax!gateway
From: [e-mail] ("Matthew T. Russotto")
Subject: Re: Segment size
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 15 Jul 91 16:55:32 GMT

Resources used to have a 32K limit-- that is gone.










Path: ucivax!gateway
From: [e-mail] (Rick Holzgrafe)
Subject: Re- Segment size
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 56
Date: 15 Jul 91 17:46:33 GMT

 Internet Mail          Re: Segment size
>Is there any way around THINK C's 32k code segment limit for libraries?

So far as I know, no. They'll need to rev their software.

>Am I the only person
>who finds this ridiculous in the age of 32-bit microprocessors?

There are reasons for the restriction, and you may or may not find them good
enough. (I know people who would give up *anything* for speed.)

There is no intrinsic need to limit segment size to 32K. It is usually done
that way on the Mac for two reasons. First, intra-segment references can always
be made with a 16-bit signed offset. This is faster than a 32-bit offset and
easier on compiler/linker writers.

Second, the jump table also has an effect on the code segment size, and this
effect *is* a restriction of the Mac OS: Any routine that is to be accessed
from *outside* its segment must be in the first 32K of its segment, because the
jump table stores the addresses of externally-referenced entry points as signed
16-bit offsets from the beginning of the segment. (And you can't fiddle with
the structure of the jump table: the OS cares about it.)

These problems can be worked around. If you are willing to pay the price of
more code and slower execution, you can use 32-bit offsets for intra-segment
references. You can get around the jump table problems by making an
intra-segment jump table in the first 32K of each large segment: the table
contains 32-bit jumps to the segment's "real" entry points, and the master
(OS-supported, inter-segment) jump table can then use 16-bit offsets to the
correct entries in the intra-segment jump tables. (Another solution is to give
the developer full control over the ordering of routines in a segment
[something Think C doesn't do] and simply require that all intra-segment
references be placed within 32K of the thing referenced, and all segment entry
points be in the first 32K. Clumsy as hell, but it keeps the smaller, faster
16-bit offsets.)

Similar limits apply to the total amount of global data, and the size of the
jump table itself: these are accessed as signed 16-bit offsets from A5,
negative (if memory serves) for globals, and positive for the jump table. You
can exceed the limit for globals, again by using 32-bit offsets. I know of no
reason why the same wouldn't apply to the jump table, but I've never heard of
this being done, and I'm less sure of my ground here.

Recent versions of MPW allow arbitrary-sized data and code segments as an
option, with the default being the old 32K limit with 16-bit offsets. I don't
know if the jump table is now allowed to exceed 32K.

-----------------------------------------------------
Rick Holzgrafe   [e-mail]   AppleLink HOLZGRAFE1
     {sun,voder,nsc,mtxinu,dual}!apple!rmh
Apple Computer, Inc.
20525 Mariani Ave. MS: 3-PK
Cupertino, CA 95014













Path: ucivax!gateway
From: [e-mail]
Subject: Problems With A Pane Sub-Class
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Original-From: cblph!jbr (j.a.brownlee)
Lines: 30
Date: 15 Jul 91 19:32:17 GMT

I have an interesting problem with a CPane sub-class using TC 4.0.5.  I created
a sub-class of CPane in which to plot an icon.  The class has three methods of
its own: an initialization method, a Dispose() method, and a Draw() method.
I create the Pane as being enclosed by the Window it is in.  When I bring up
a window with an icon in it, everything is happy.  However, when I Hide() the
window, then Show() it, the icon is not replotted.

Using the debugger, I found that my Draw() method is being called, but it
appears that the Pane is not being accumulated into the update region to be
plotted at the next update event.  I put a Refresh() call in the Draw() method,
and sure enough, my icon is plotted continuously, as expected.  Checking the
the source for CPane shows that the Show() (as documented in the manual on page
336).  This lead me to the actual problem -- my Pane's Show() method is never
getting called.  I have several other items in the window (CButton, CCheckBox,
CPicture, etc.) and they do seem to be updated correctly.

After stepping through the code several times, I still don't quite understand
why my Show() method isn't being called.  It has something to do with the
DoForEach() loop through the Subviews of the Window, but I don't see what.
It seems the only call being made for my Pane is the Draw() method.  Do I need
to override some other method?

Has anyone else had a similar problem?  I could use any advice on how to attack
this that anyone might have.  I guess my next step is to go back to the
debugger again...

   ^      _   Joe Brownlee, Analysts International Corporation @ AT&T Bell Labs
  /_\  @ / `  471 E Broad St, Suite 1610, Columbus, Ohio 43215   [phone]
 /   \ | \_,  E-mail: [e-mail]     Who pays attention to what _I_ say?
 "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk










Path: ucivax!gateway
From: [e-mail] ("Matthew T. Russotto")
Subject: Re: segment size
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 16 Jul 91 14:17:37 GMT

The 32K resource limit was a 64K ROM limit-- it has been gone for years.
PC-relative branches are limited to 32K in each direction on the 68000-- that
can be gotten around, but at a high cost in efficiency.  On the 68020, it
is fairly simple to get around (branches can have a 32-bit displacement).
Global data is limited to 32K if you use the a5 scheme, but I wish compilers
would support using a different scheme.










Path: ucivax!gateway
From: [e-mail]
Subject: Think Pascal in Think C
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 16 Jul 91 21:36:03 GMT

Hi there,

    The subject line says it all, How can I include think pascal libraries
and/or projects in think C ? I've checked both manual (pascal and C) and
seems only possible in one direction (C lib and/or proj included in Think
pascal projs). What is the matter with Think C , why can't it handle it ?
Am I doing something wrong ?



                                               Carlos Bazzarella.











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Re: Think Pascal in Think C
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 16 Jul 91 21:36:03 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 17 Jul 91 17:41:35 GMT

   The subject line says it all, How can I include think pascal
   libraries and/or projects in think C?

THINK Pascal v3.0 and later uses MPW's object file format for writing
libraries.  Because of this, THINK C users can convert Pascal
libraries by using the oConv utility that comes with THINK C.  The
only catch is that oConv doesn't know about Pascal 3.0 libraries.  So,
you must convince it that it's dealing with an MPW .o file.

To do this, you must first rename your Pascal library so its filename
ends in a ".o".  Next, you must change the creator type for the
library from "PJMM" to "MPS ".  You can use ResEdit or some other
utility to change a file's type.

Note that oConv can't handle multisegment libraries, so if you have a
library with more than 32K of code, you'll have to import it using one
library for each segment.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] ("Erik A. Johnson")
Subject: StopAlert() behavior ok w/Debugger, not ok without? help!
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 14
Date: 18 Jul 91 01:41:09 GMT

I have a project in which StopAlert() is called.  If I have the THINK C
Debugger on, the Alert works fine.  But without the debugger, the stopIcon
doesn't show up and the default-button-outline around the OK button isn't
drawn.

Any ideas?  Thanks.


Erik A. Johnson        \    Internet: [e-mail]     \       |
------------------------\    AmericaOnline: ErikAJ                   \    --+--
Graduate Student         \--------------------------------------------\     |
Aero/Astro Engineering    \  "Jesus said to him, 'I am the way, and    \    |
University of Illinois at  \  the truth, and the life; no one comes to  \   |
   Urbana-Champaign (UIUC)  \  the Father except through me.'" (Jn14:6)  \










Path: ucivax!gateway
From: [e-mail] ("Erik A. Johnson")
Subject: Re: StopAlert() behavior ok w/Debugger, not ok without? help!
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 18 Jul 91 05:48:52 GMT

Sorry all, I found a work-around.  The StopAlert() I was trying to display
was at the very beginning of my program, before I had gone through my
Event loop.  I remembered seeing something sometime about dialogs having
problems at the very beginning of a code unless WaitNextEvent() is called
a couple of times before.

Well, that fixed it, but I'm still curious as to why this is the case.
Any ideas?


Erik A. Johnson        \    Internet: [e-mail]     \       |
------------------------\    AmericaOnline: ErikAJ                   \    --+--
Graduate Student         \--------------------------------------------\     |
Aero/Astro Engineering    \  "Jesus said to him, 'I am the way, and    \    |
University of Illinois at  \  the truth, and the life; no one comes to  \   |
   Urbana-Champaign (UIUC)  \  the Father except through me.'" (Jn14:6)  \










Path: ucivax!gateway
From: [e-mail] ("James E. O'Dell")
Subject: Mac/gnuucp under System 7.0
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: "James E. O'Dell" <[e-mail]>
Organization: Fort Pond Research
Lines: 24
Date: 18 Jul 91 12:31:34 GMT

>Equipment: Mac Plus
>                  4 megs of ram
>
>I am running 4.3 gnu uucp, I just upgraded to system 7 and I when I
>run the uucico program, and the window is very large (It can't fit on
>my mac plus).
>It worked fine when I was using system 6.0.7.  I tried to recomple it
>with the system 7 headers and libraries from symantec but no go.
>Have other people reported this bug??  Do you have a fix for it???

I personally have not upgraded to system 7.0 yet because so much of my
environment needs upgrading...

However, other users have reported that under system 7.0 Mac/gnuucp
worked O.K. It may be that they have not tried on small monitor Mac's.

It could also be an incompatibility between the Symantex Unix console
library and System 7.0 Anyone on the THINK-C mailing list know
about this?

Thanks,
Jim












Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: StopAlert() behavior ok w/Debugger, not ok without? help!
Message-ID: <[e-mail]>
In-Reply-To: "Erik A. Johnson"'s message of 18 Jul 91 05:48:52 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 18 Jul 91 13:45:34 GMT

Erik wrote:
   Sorry all, I found a work-around.  The StopAlert() I was trying to
   display was at the very beginning of my program, before I had gone
   through my Event loop.  I remembered seeing something sometime
   about dialogs having problems at the very beginning of a code
   unless WaitNextEvent() is called a couple of times before.

   Well, that fixed it, but I'm still curious as to why this is the
   case.  Any ideas?

The THINK C Debugger uses a WaitNextEvent() call that it executes in
your heap to suspend your app and bring it to the foreground, in order
to force a context switch.  This occurs on breakpoints and
watchpoints, or if you single-step through your code.  This call to
WaitNextEvent probably lets the dialog manager do its bit.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Ephraim Vishniac)
Subject: Re: Mac/gnuucp under System 7.0
Message-ID: <[e-mail]>
In-Reply-To: Your message of "18 Jul 91 12:31:34 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 18 Jul 91 14:08:38 GMT


   From: "James E. O'Dell" <[e-mail]>
   Date: 18 Jul 91 12:31:34 GMT

   >I am running 4.3 gnu uucp, I just upgraded to system 7 and I when I
   >run the uucico program, and the window is very large (It can't fit on
   >my mac plus).

   It could also be an incompatibility between the Symantex Unix console
   library and System 7.0 Anyone on the THINK-C mailing list know
   about this?

It might be wider spread than that. Somebody from BCS posted recently
in one of the Mac groups that BiPlane 2.0, a shareware spreadsheet,
opens an extremely (infinitely?) wide window by default on his system.
I ran it on my system, saw no problem, and compared notes with him.
He was running 7.0, I'm running 6.0.5.











Path: ucivax!gateway
From: [e-mail] (Francois Menneteau)
Subject: Re: segment size
Message-ID: <[e-mail]>
In-Reply-To: "James F. Kennedy"'s message as of Jul 15, 16:16.
Newsgroups: fa.think-c
Organization: IMAG Institute, University of Grenoble
Lines: 17
Date: 19 Jul 91 10:25:12 GMT

Dans votre courrier du 15 Jul vous ecrivez :
>
>Nick Rothwell writes:

>Hmmm..I seem to remember that in pre-system 7.0, code resources were limited
>to 32K because of the inability for the Resource manager to handle
>CODE resources larger than 32K.  I also seem to remember something about

Wrong ! Look at the 64K, and the 600K PCODE resources in Word 4.0. I Know
it because my resources dump/disass/editor crashed the first time I open
them. Now it works fine...

--
Francois Menneteau ()   __|||||__   () "... I had their lives in my hands
================== ()    /O   O\    () their fate their fortune in my visions
[e-mail]       ()    - .|. -    () No one believed in my true prophecy
================== ()     \=^=/     () And now it's too late."  (Iron Maiden)










Path: ucivax!gateway
From: [e-mail]
Subject: THINK C addition request
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 19 Jul 91 15:02:20 GMT

Please add me to this discussion group.
Thanks.


//Dan
The University of Michigan
Computer-Aided Engineering Network
Macintosh Systems Administration











Path: ucivax!gateway
From: pixar!planetex![e-mail] (Flip Phillips)
Subject: Re: Mac/gnuucp under System 7.0
Message-ID: <9107221634.AA08338@pixar>
X-Mailer: Mail Reader (2.0b8 4jun91)
Newsgroups: fa.think-c
Reply-To: pixar!planetex![e-mail]
Organization: Planet Ex
Lines: 26
Date: 22 Jul 91 17:07:58 GMT

On Thu, 18 Jul 91, pixar!ucbvax!fpr.com!jim (James E. O'Dell) wrote:
>>Equipment: Mac Plus
>>                  4 megs of ram
>>
>>I am running 4.3 gnu uucp, I just upgraded to system 7 and I when I
>>run the uucico program, and the window is very large (It can't fit on
>>my mac plus).
>>It worked fine when I was using system 6.0.7.  I tried to recomple it
>>with the system 7 headers and libraries from symantec but no go.
>>Have other people reported this bug??  Do you have a fix for it???
[...]
>It could also be an incompatibility between the Symantex Unix console
>library and System 7.0 Anyone on the THINK-C mailing list know
>about this?


Which version of the c-compiler? There have been many mutations of the
compiler lately, (well, OK 2 or 3), 4.0.5 is the most recent one I can find,
has some fixes for 7.0 compatible code generation. Give that a shot if you
haven't.

-- flip


Flip Phillips
Planet Ex










Path: ucivax!gateway
From: [e-mail] (Kevin Whitley)
Subject: opening serial ports
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 22 Jul 91 18:55:46 GMT


It used to be, in the stdio libraries of THINK C version 3.0 & earlier,
that one could open serial ports by opening "files" names .AOut, .AIn
.BOut .BIn.  In the stdio libraries that came with version 4.0 this no
longer works.  Is there a way to open the serial ports with the stdio
libraries?

Kevin Whitley
[e-mail]












Path: ucivax!gateway
From: [e-mail] (Operator)
Subject: Forwarding: dropped mail
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 22 Jul 91 21:25:08 GMT

This message was not delivered due to problems at our site. It is being resent.
The following is a copy of the message:

Received: from ics.uci.edu (-:ics.uci.edu:-) by yonge.csri.toronto.edu via TCP with SMTP id AA27989; Mon, 15 Jul 91 02:18:52 EDT
Received: from ics.uci.edu by ics.uci.edu id aa14683; 14 Jul 91 21:53 PDT
Received: from USENET by ics.uci.edu id aa14665; 14 Jul 91 21:51 PDT
From: Jamie McCarthy <[e-mail]>
Subject: The THINK Reference
Message-Id: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Date: 15 Jul 91 04:51:19 GMT
To: [e-mail]

Any comments from users of the THINK(tm) Reference?  I generally prefer
paper to on-line reference, but it sounds pretty good.

"...THINK Reference integrates smoothly with both THINK C and THINK
Pascal" says the cover letter I got.  How smoothly?  Ideally, you could
hilite the name of a toolbox call, select a menu item, and have
information about it pop up in a window.  Or does it work differently?
--
 Jamie McCarthy            [e-mail] or [e-mail]
 Disclaimer:  it's my responsibility iff they're my words.
 There's not much point in wandering around out here, and you can't
 explore the cave without a lamp. So let's just call it a day.











Path: ucivax!gateway
From: [e-mail] (Operator)
Subject: Forwarding: dropped mail
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 52
Date: 22 Jul 91 21:34:33 GMT

This message was not delivered due to problems at our site. It is being resent.
The following is a copy of the message:

Received: from ics.uci.edu (-:ics.uci.edu:-) by yonge.csri.toronto.edu via TCP with SMTP id AA03906; Mon, 15 Jul 91 14:38:34 EDT
Received: from ics.uci.edu by ics.uci.edu id aa16360; 15 Jul 91 9:18 PDT
Received: from USENET by ics.uci.edu id aa16318; 15 Jul 91 9:16 PDT
From: "James F. Kennedy" <[e-mail]>
Subject: Re: segment size
Message-Id: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Posted-Date: Mon, 15 Jul 91 12:16:18 EDT
Newsgroups: fa.think-c
Date: 15 Jul 91 16:16:43 GMT
To: [e-mail]


Nick Rothwell writes:
>
> No, I find it a little silly too. My understanding is that the limit is due
> to the Resource Manager handling the CODE resources. Since resources can
> only be 32K in size, code segments are similarly limited

Jamie McCarthy writes:
>
>Resources can be much larger. I've never found a limit; without IM
>handy, I'd guess they could be the full 4 gigs.
>
>The problem, I believe, is that some (ahem) compiler writers don't want
>to handle the problem of >32K branches that arise when you have a >32K
>code space. (No, wait, don't flame me if I'm wrong--maybe it _is_ a
>MacOS restriction, I don't really know.  ;-)
>
>I do know, however, that there's no good reason for limiting local
>variables to 32K, which (last I checked) THINK C did.  Gr.

Hmmm..I seem to remember that in pre-system 7.0, code resources were limited
to 32K because of the inability for the Resource manager to handle
CODE resources larger than 32K.  I also seem to remember something about
the way in which the mac os handles relocatable code is also a limiting
factor.  Lord knows how it is in system 7.0 - one would think they fixed
this annoying problem (the mac is the only 32 bit system that I know
of restricted to 32K code segments).

 I do know that global data is limited to 32K because of the A5_world
scheme....maybe this has something to do with code segments too...I'll
have to go back and take a look.

            James
--
James F. Kennedy        "Don't eat it if you don't like it."
[e-mail]        "This is MY opinion:)"











Path: ucivax!gateway
From: [e-mail] (Operator)
Subject: Forwarding: dropped mail
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 45
Date: 22 Jul 91 21:36:03 GMT

This message was not delivered due to problems at our site. It is being resent.
The following is a copy of the message:

Received: from ics.uci.edu (-:ics.uci.edu:-) by yonge.csri.toronto.edu via TCP with SMTP id AA06108; Mon, 15 Jul 91 18:33:48 EDT
Received: from ics.uci.edu by ics.uci.edu id aa09625; 15 Jul 91 12:34 PDT
Received: from USENET by ics.uci.edu id aa09608; 15 Jul 91 12:32 PDT
From: [e-mail]
Subject: Problems With A Pane Sub-Class
Message-Id: <[e-mail]>
Newsgroups: fa.think-c
Original-From: cblph!jbr (j.a.brownlee)
Date: 15 Jul 91 19:32:17 GMT
To: [e-mail]

I have an interesting problem with a CPane sub-class using TC 4.0.5.  I created
a sub-class of CPane in which to plot an icon.  The class has three methods of
its own: an initialization method, a Dispose() method, and a Draw() method.
I create the Pane as being enclosed by the Window it is in.  When I bring up
a window with an icon in it, everything is happy.  However, when I Hide() the
window, then Show() it, the icon is not replotted.

Using the debugger, I found that my Draw() method is being called, but it
appears that the Pane is not being accumulated into the update region to be
plotted at the next update event.  I put a Refresh() call in the Draw() method,
and sure enough, my icon is plotted continuously, as expected.  Checking the
the source for CPane shows that the Show() (as documented in the manual on page
336).  This lead me to the actual problem -- my Pane's Show() method is never
getting called.  I have several other items in the window (CButton, CCheckBox,
CPicture, etc.) and they do seem to be updated correctly.

After stepping through the code several times, I still don't quite understand
why my Show() method isn't being called.  It has something to do with the
DoForEach() loop through the Subviews of the Window, but I don't see what.
It seems the only call being made for my Pane is the Draw() method.  Do I need
to override some other method?

Has anyone else had a similar problem?  I could use any advice on how to attack
this that anyone might have.  I guess my next step is to go back to the
debugger again...

   ^      _   Joe Brownlee, Analysts International Corporation @ AT&T Bell Labs
  /_\  @ / `  471 E Broad St, Suite 1610, Columbus, Ohio 43215   [phone]
 /   \ | \_,  E-mail: [e-mail]     Who pays attention to what _I_ say?
 "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk











Path: ucivax!gateway
From: [e-mail] (Operator)
Subject: Forwarding: dropped mail
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 22 Jul 91 21:36:03 GMT

This message was not delivered due to problems at our site. It is being resent.
The following is a copy of the message:

Received: from ics.uci.edu (-:ics.uci.edu:-) by yonge.csri.toronto.edu via TCP with SMTP id AA25514; Thu, 11 Jul 91 15:38:45 EDT
Received: from ics.uci.edu by ics.uci.edu id aa06771; 11 Jul 91 9:24 PDT
Received: from USENET by ics.uci.edu id aa06748; 11 Jul 91 9:21 PDT
From: [e-mail]
Subject: Re: How do you write a popup MDEF?
Message-Id: <[e-mail]>
Newsgroups: fa.think-c
Date: 11 Jul 91 16:21:03 GMT
To: [e-mail]

I don't have the answer to your questions but I do have a suggestion.
Lord of the Files (the current Developer CD), contains a folder called
"Menu Defproc 1.0.2" which is a MDEF written in MPW C.  It's pretty
easy follow, and really helped me with my MDEF.  (But I didn't have to
support scrolling or pop-ups....)
  --dave











Path: ucivax!gateway
From: [e-mail] ("Edward J. Huff")
Subject: 32k limits
Message-ID: <[e-mail]>
X-VMS-Cc: HUFF
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 9
Date: 23 Jul 91 15:11:40 GMT
X-Envelope-to: [e-mail]
X-Organization: NYU Medical Center, 550 First Ave., New York

MPW 3.2 has a "huge" model which lifts the 32k limits on data.
The problem arises from the desire to use 4 byte instructions to
reference global data.  Any given compiled module must decide at
compile time how long each instruction is.  If you want to have
>32k global data, you must use 6 byte instructions for ALL references
to global data.  I don't know if the 32k code segment limit will also
be removed, but the similar effect is you have to use 6 byte jump
instructions (not available on 68000 in PC relative mode) for all
references to modules not in the present compilation.










Path: ucivax!gateway
From: [e-mail]
Subject: two TCL design q's
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 33
Date: 23 Jul 91 20:50:04 GMT



hi all,

i have two design questions about the think class library:

    (1)  why is it that an "Offset" message to a pane doesn't
         cause its hEncl & vEncl to change?  if the pane moves
         within its enclosure (ie, the reason for an Offset msg),
         then why don't the variables that track its location
         within its enclosure change also?

    (2)  why does the "FindSubview"/"View_Contains" duo look
         at a subview's "wantsClicks" variable only AFTER the
         subview is found?

to clarify #2:  i have two types of subviews in my pane.  one type fills
its frame with data and always wants clicks.  another type fills only
part of its frame, and only sometimes wants clicks.  a situation can
arise when the "sparse" subview's frame overlaps the "full" subview's
frame.  no one notices, since the data in the "full" subview" is not
obscured.  when the main pane goes to check its subviews for a dispatch-
click, it finds only the sparse subview, never the full one, even when
the sparse subview doesn't want clicks.

i've found workarounds for both of these problems. any ideas on why
they were implemented this way to begin with??


:jeff bellsey

[e-mail]











Path: ucivax!gateway
From: [e-mail] (Chris McNeil)
Subject: ADSP & Launching questions
Message-ID: <[e-mail]>
X-Mailer: QuickMail/SMTP interface.
Newsgroups: fa.think-c
Lines: 7
Date: 24 Jul 91 02:27:59 GMT

Where can I get information on writing programs that use ADSP. Also how do I
launch a program from another program using Think C. ( does anyone have some
code that does this that they would share ?)

Thanks
Chris McNeil
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("James E. O'Dell")
Subject: RE: Re: Mac/gnuucp under System 7.0
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: "James E. O'Dell" <[e-mail]>
Organization: Fort Pond Research
Lines: 24
Date: 24 Jul 91 02:41:16 GMT

>>>I am running 4.3 gnu uucp, I just upgraded to system 7 and I when I
>>>run the uucico program, and the window is very large (It can't fit on
>>>my mac plus).
>>>It worked fine when I was using system 6.0.7.  I tried to recomple it
>>>with the system 7 headers and libraries from symantec but no go.
>>>Have other people reported this bug??  Do you have a fix for it???
>[...]
>>It could also be an incompatibility between the Symantex Unix console
>>library and System 7.0 Anyone on the THINK-C mailing list know
>>about this?
>
>
>Which version of the c-compiler? There have been many mutations of the
>compiler lately, (well, OK 2 or 3), 4.0.5 is the most recent one I can find,
>has some fixes for 7.0 compatible code generation. Give that a shot if you
>haven't.

I got mail from johnj saying that he had install system 7.0 "wrong" and
when he reinstalled it the problem disappeared. I dying to know
how he installed it "wrong"

Jim












Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: two TCL design q's
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 23 Jul 91 20:50:04 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 24
Date: 24 Jul 91 18:50:52 GMT

       (1)  why is it that an "Offset" message to a pane doesn't
        cause its hEncl & vEncl to change?

This is a bug in the TCL, and it will be fixed in the next major
release.

       (2)  why does the "FindSubview"/"View_Contains" duo look
        at a subview's "wantsClicks" variable only AFTER the
        subview is found?

If you have a non clickable pane obscuring (covering visually) a
clickable one, then you won't ever get click events for the obscured
clickable pane.  This is, I guess, a shortcoming in the TCL for apps
that have layered panes.  Offhand, I don't know why we do it the way
we do, and I can't see anything wrong with modifing CView::FindSubview
(and changing View_Contains) so that it checks for clickability at the
same time it checks for visibility.  I'll pass this one on as a
suggestion for the TCL.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: QuickDraw32 bit
Message-ID: <9107251528.AA26399@husc10>
Newsgroups: fa.think-c
Lines: 16
Date: 25 Jul 91 15:28:56 GMT

Friends,

I'm trying to use offscreen GWorlds of 32 bit quick draw for some
animation but ran into a snag.  The QuickDraw32Bit.h file from the uci
archive does not have a definition for the routine GetGWorldPixMap.
Now I guess I could figure how to get at this field of the GWorld
record but for "future compatibility" I would prefer to use this
function.  Is there a revised QuickDraw32Bit.h which has this defined?

On a related note, there seems to be a typographical type error in the
aforementioned header file.  The routine which is called UnlockPixels
in IM VI is called UnLockPixels in the header.

Thanks in advance

--Erik










Path: ucivax!gateway
From: [e-mail] ("Matthew T. Russotto")
Subject: Re:  QuickDraw32 bit
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 25 Jul 91 18:28:55 GMT

GetGWorldPixMap?  It's not in my header files either.  What is it supposed
to do?  I've got a GetPixBaseAddr:
pascal Ptr GetPixBaseAddr (PixMapHandle pm)
    = {0x700F,0xAB1D};











Path: ucivax!gateway
From: [e-mail]
Subject: Resedit example editor code in Think C
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 25 Jul 91 20:29:37 GMT

Has anyone tried to convert the example code for writing a Resedit
editor or picker from MPW into Think C? The hard part seems to be the
assembly routines. I tried converting them into inline assembler, but
one of the files (RSSC.a) has a jump table structure, with things like
dc.w routine1-routine2
and Think C doesn't allow this.

-- Brian
_____________________________________________________
Brian Feinberg <[e-mail]>
UUCP:  oliveb!cirrusl!brian
CIS:   73617,2470
AOL:   BrianF










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: QuickDraw32 bit
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 25 Jul 91 15:28:56 GMT <9107251528.AA26399@husc10>
Newsgroups: fa.think-c
Lines: 14
Date: 25 Jul 91 21:56:11 GMT

Here's the glue for PixMapHandle:

pascal PixMapHandle GetGWorldPixMap(GWorldPtr offscreenGWorld)
    = {0x203C,0x0004,0x0017,0xAB1D};

Re: UnlockPixels vs. UnLockPixels; it's not a typo, Apple just changed
it between 32 bit QuickDraw and System 7.0.  It's the same trap.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]











Path: ucivax!gateway
From: [e-mail] (Tobias Kunze)
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X400-Received: by /PRMD=tu-berlin/ADMD=dbp/C=de/;
    Relayed; 26 Jul 91 03:10:18+0200
Lines: 66
Date: 26 Jul 91 01:12:17 GMT

Sound Manager Clicks

I'm working on a project which simulates most of the features of common Unix
computer music synthesis systems, including the basic capability of reading
large soundfiles from disk. Sounds fine so far, if I could figure out where
these little 'clicks' are from. Thus I spent two weeks to trace it down, but I
couldn't find anything wrong with my code.
To be more precise: I repeatedly read 22200 16-bit samples from the disk,
convert them to 8-bit offset format (0x00-0xFF), attach a standard sound header
to the converted buffers in memory, and finally send each of them to the Sound
Manager via SndDoCommand(...,&mybufferCmd,...). Of course, all channel setup
and release is done, too.
The 'click' always (actually: 'sometimes', see later on) occurs between every
two buffers.
Now the strange thing: I've tested the integrity of the buffers just at the
point where they are sent to the sampledSynth from within Macsbug 6.2 (in fact,
I logged the output to a file, extracted all buffers, and concatenated them
into one single file which I could open with SoundEdit and listen to) and they
turned out to be perfectly clean.
Let me emphasize that this is in no way the old problem with the Sound Driver
discussed somewhere in TechNote #19 (+/- 10). I have no idea, what's going
wrong.
This problem persists on my SE/30 regardless whether I'm running 6.0.4-6 or
6.0.7/7.0 and seems to be fully independent of how much Inits are loaded, or
whether Multifinder is running or not.

Now the bad thing: It seems to me now that this is a *undocumented* bug in the
Sound Manager... Why?
        -> I downloaded TcpPlay (written by Bill Stafford, Malcolm Slaney, and
           Richard Tsoi, Advanced Technology Group), which basically does it
           the same way, and tested it on my soundfiles. Guess, what...
              dzzz 'click' dzzz 'click' dzzz 'click'...
        -> Funny enough, this seemed not to happen with the soundfiles they
           provided!
        -> Confused by that, I finally found out, that Apple is *nearly* right
           if they claim: 'playing two or more buffers end-to-end is guaranteed
           to sound just as though the buffers had been concatenated into a
           longer buffer...' (IM V-485, similar in J. Reekes' interim chapter),
           the only caveat being: there's *always* a click. You just normally
           wouldn't hear it if your soundfiles contain  non-sinusoidal signals,
           e.g., speech, recorded music, other noisy signals, or simply
           silence.
           However,I managed to notice it even on a soundfile containing
           nothing but white noise by decreasing the playback sample rate to
           some silly value as 1000 Hz.

Nevertheless, I still hesitate to end up with this. In fact, as I am not a
experienced programmer, I can't really believe that I'm right and Apple is -at
least partially- wrong. Also, as I *have* to find a way to circumvent these
annoying clicks, I need really help!
Did anyone out there experience the same phenomenon? Or heard about the
problem?
Does anyone know about a nifty trick to bypass it?
I would greatly appreciate *any* hints and will -of course- post a summary of
all replys which may get to me directly.

Thanks a lot,

Tobias Kunze
Hochschule der Kuenste Berlin
Technische Universitaet Berlin
<[e-mail]>

P.S.:  English is  n o t  my first language!
       Please don't laugh at it. Correct me.











Path: ucivax!gateway
From: [e-mail] ("Erik A. Johnson")
Subject: Re: Resedit example editor code in Think C
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 26 Jul 91 05:06:25 GMT

Yes, I've got the ResEdit extensions examples running in THINK C,
thanks to a little help from Phil Shapiro at Symantec.

I've been trying to clean-up an example editor (that does a little more
than the example from Apple MacDTS) written with THINK C.  (However,
time constraints have put it temporarily on hold.)  I'll e-mail the
entire project or just the ?*.a files to whoever wants them.  (If
there is enough interest, I could also send it over the think-c
mail-list and/or post it to sumex.)


Erik A. Johnson        \    Internet: [e-mail]     \       |
------------------------\    AmericaOnline: ErikAJ                   \    --+--
Graduate Student         \--------------------------------------------\     |
Aero/Astro Engineering    \  "Jesus said to him, 'I am the way, and    \    |
University of Illinois at  \  the truth, and the life; no one comes to  \   |
   Urbana-Champaign (UIUC)  \  the Father except through me.'" (Jn14:6)  \










Path: ucivax!gateway
From: [e-mail] (Michael McGuffey)
Subject: Think-C v5.0 in MacWAREHOUSE ad.
Message-ID: <[e-mail]>
X-VMS-Cc: MCGUFFEY
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 19
Date: 26 Jul 91 16:17:58 GMT
X-Envelope-to: [e-mail]


FYI:

The MacWAREHOUSE ad in the newest MacWorld (Sep 91) shows Think C v5.0
with a price of $209.  When I called, they said the computer was listing
v4.0, but it was out of stock.  The girl on the other end said the
ad lists 5.0 because that's what is expected to be shipped... in about
1 1/2 weeks.

I thought I'd save people some time calling (and MacWAREHOUSE some 1-800
call costs) and send this to the list.

--michael
-----------------------------------------------------------------------------
Michael McGuffey, Director      BITNET:   mcguffey@marshall
Office of Institutional Research  Internet: [e-mail]
Marshall University          Phone:    [phone]
Huntington, WV 25755          FAX:      [phone]
-----------------------------------------------------------------------------










Newsgroups: fa.think-c
Path: ucivax!orion.oac.uci.edu!eabu111
From: [e-mail] (Steven Luh)
Subject: Re: Think-C v5.0 in MacWAREHOUSE ad.
Message-ID: <[e-mail]>
Organization: University of California, Irvine
References: <[e-mail]>
Date: Fri, 26 Jul 1991 18:54:07 GMT
Lines: 27

In article <[e-mail]> [e-mail] (Michael McGuffey) writes:
>
>FYI:
>
>The MacWAREHOUSE ad in the newest MacWorld (Sep 91) shows Think C v5.0
>with a price of $209.  When I called, they said the computer was listing
>v4.0, but it was out of stock.  The girl on the other end said the
>ad lists 5.0 because that's what is expected to be shipped... in about
>1 1/2 weeks.
>
>I thought I'd save people some time calling (and MacWAREHOUSE some 1-800
>call costs) and send this to the list.
>
>--michael
>-----------------------------------------------------------------------------
>Michael McGuffey, Director      BITNET:   mcguffey@marshall
>Office of Institutional Research  Internet: [e-mail]
>Marshall University          Phone:    [phone]
>Huntington, WV 25755          FAX:      [phone]
>-----------------------------------------------------------------------------

One question, do you guys know if Think C 5.0 will be a free upgrade via
anonymous FTP or do we have to send in some moeny??

Steve












Path: ucivax!gateway
From: [e-mail]
Subject: Re: Think-C v5.0 in MacWAREHOUSE ad.
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 25
Date: 26 Jul 91 19:44:33 GMT

You would think that Symantec would do SOMETHING about the BIGGEST flaws in
THINK C. Sure, now we can make REALLY small but fast code with the new 5.0
compiler, but HEY:

*   We still have the most pitiful debugger on the face of the planet
(although, we DO have one). Why can't we have something with the
functionality of THINK Pascal's debugger?

*   We STILL can't specify what we'd like our default font and size to be.
Well, heck, it's not a BIG deal, but it IS a pain!!

*   We still have a pretty sad interface. There's a lot of things out
there, and we've still got the bare bones. Now, I might add that I kinda
LIKE bare bones stuff.. but I'd like the OPTION at least of a real
interface.


Anyways, enuff grumblin'....


//Dan
The University of Michigan
Computer-Aided Engineering Network
Macintosh Systems Administration











Path: ucivax!gateway
From: [e-mail]
Subject: Re: Think-C v5.0
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 34
Date: 26 Jul 91 21:22:00 GMT


first, is there really such a thing?

second, is it really shipping in "1-1/2 weeks"?

third, why didn't we hear about it before macWH?

also:

> *   We still have the most pitiful debugger on the face of the planet
> (although, we DO have one). Why can't we have something with the
> functionality of THINK Pascal's debugger?

perhaps you've never used sade!  (they don't call it that for
nothin' ;-)  i give think C about 1000% higher marks than sade.
though i look forward to seeing what think pascal looks like...

> *   We still have a pretty sad interface. There's a lot of things out
> there, and we've still got the bare bones. Now, I might add that I kinda
> LIKE bare bones stuff.. but I'd like the OPTION at least of a real
> interface.

sorry, i like the interface.  get yerself 4+ or some other super-
enhancer, and suddenly there's nothing you can't do quickly.

more apologies for the tone here, but i just love think c.  keep
mpw away from me.

(hey, could someone get paid for saying stuff like this if they
wanted to? ;)

:jeff bellsey

[e-mail]










Newsgroups: fa.think-c
Path: ucivax!orion.oac.uci.edu!eabu111
From: [e-mail] (Steven Luh)
Subject: Gestalt Manager header
Message-ID: <[e-mail]>
Organization: University of California, Irvine
Date: Fri, 26 Jul 1991 21:34:35 GMT
Lines: 14

I was just looking at the new Gestalt manager and was wondering where I can get
the header file for Think C so I can access it.  I got the Gestalt file that
was on ICS.UCI.EDU but it seems to be a little out dated or something.  Also,
I got a source code from my friend that says it uses the Gestalt Manager (He
said it was the exact sample code that was given on Think Reference) but I get
a Link error because it doesn't recognize the command Gestalt, whats going on?

It compiles fine but doesn't seem to recognize it.

BTW, I'm new at mac programming so please elaborate as much as possible (any
hints/tips to the Think C manuals would help too!).

Steven











Path: ucivax!gateway
From: [e-mail]
Subject: Think-C v5.0 in MacWAREHOUSE ad.
Message-ID: <9107262332.AA08830@husc10>
In-Reply-To: [e-mail]'s message of 26 Jul 91 19:44:33 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 26 Jul 91 23:33:18 GMT

I posted something about this to c.s.m.p.  What I was really looking
forward to was a full C++ implementation.  Anyone else looking for
C++?

--Erik











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Think-C v5.0 in MacWAREHOUSE ad.
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 26 Jul 91 19:44:33 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 27 Jul 91 01:29:11 GMT

   * We STILL can't specify what we'd like our default font and size
   to be.  Well, heck, it's not a BIG deal, but it IS a pain!!

You can change the default font, size and number of tabs displayed in
a source code window by modifying the 'CNFG' 0 resource in THINK C.
This is described someplace in the Editor chapter (don't have my
manuals on hand) -- probably on the same page that describes the Set
Font and Tabs dialog box.

Re: the MacWarehouse ad: The official line on this is that it was a
media scheduling error.  As with any of our products, a new release
will occur when and if a product is fully tested and is ready to be
released, no sooner.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Re: QuickDraw32 bit
Message-ID: <[e-mail]>
In-Reply-To: Your message of 25 Jul 91 18:28:55 GMT.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 27 Jul 91 02:20:08 GMT



>GetGWorldPixMap?  It's not in my header files either.  What is it supposed
>to do?  I've got a GetPixBaseAddr:
>pascal Ptr GetPixBaseAddr (PixMapHandle pm)
>    = {0x700F,0xAB1D};

Look in IM VI for the details.  This is from the 'QDOffscreen.h' MPW C
header.  It may or may not work with Think C, haven't tested it.

pascal PixMapHandle GetGWorldPixMap(GWorldPtr offscreenGWorld)
    = {0x203C,0x0004,0x0017,0xAB1D};

Mike.
_____________________________________________________________________________
Michael A. Kelly                                   America Online: Michael792
[e-mail] or [e-mail]              Compu$erve: 73567,1651
_____________________________________________________________________________










Path: ucivax!gateway
From: [e-mail] (Daniel Edward Rudman)
Subject: Re: Think-C v5.0 in MacWAREHOUSE ad.
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 27 Jul 91 06:37:58 GMT

Hey, thanks for the tip, Phil. I must have missed that blurb on the default
stuff (scratches head, now WHERE the heck is that stuff?).

Oops on the media goof.  Hey, the 5.0 compiler *IS* nice.

//Dan










Path: ucivax!gateway
From: [e-mail] (Daniel Edward Rudman)
Subject: Re: Think-C v5.0
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 27 Jul 91 06:39:20 GMT

I like THINK C a lot, Jeff, don't get me wrong. I was just making the point
that it could use a LOT of improvement interface-wise. I *HATE* MPW and
I hate MacApp and I can't STAND Pascal, so THINK C is a great choice!

//Dan










Path: ucivax!gateway
From: [e-mail]
Subject: debugger window position (was Think-C v5.0 in MacWAREHOUSE ad.)
Message-ID: <9107271106.AA12444@husc10>
In-Reply-To: Phil Shapiro's message of 27 Jul 91 01:29:11 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 27 Jul 91 11:06:48 GMT

The appended note brings up a question I've had.  On my ordinary Mac
IIx the debugger windows obscure part of the console i/o window.  I
can resize and move them but this is a pain during the development
cycle.  Is it possible to muck with the resources in Think C to change
the default locations of the debugger windows?

--Erik ([e-mail])

   From: Phil Shapiro <[e-mail]>

      * We STILL can't specify what we'd like our default font and size
      to be.  Well, heck, it's not a BIG deal, but it IS a pain!!

   You can change the default font, size and number of tabs displayed in
   a source code window by modifying the 'CNFG' 0 resource in THINK C.
   This is described someplace in the Editor chapter (don't have my
   manuals on hand) -- probably on the same page that describes the Set
   Font and Tabs dialog box.

   [stuff about 5.0 deleted]

       -phil
   ----
      Phil Shapiro                           Technical Support Analyst
      Language Products Group                     Symantec Corporation
           Internet: [e-mail]











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: debugger window position (was Think-C v5.0 in MacWAREHOUSE ad.)
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 27 Jul 91 11:06:48 GMT <9107271106.AA12444@husc10>
Newsgroups: fa.think-c
Lines: 16
Date: 27 Jul 91 16:22:30 GMT

Erik writes:
   The appended note brings up a question I've had.  On my ordinary Mac
   IIx the debugger windows obscure part of the console i/o window.  I
   can resize and move them but this is a pain during the development
   cycle.  Is it possible to muck with the resources in Think C to change
   the default locations of the debugger windows?

No, it's not possible.  The Debugger dynamically places its windows,
so there's no resource to change.

As an alternative, you may want to try using the console_options to
place the console window so the Debugger's window's won't interfere
with it.  Also, you could write a QuicKeys macro to move the windows
around when the debugger comes up.

    -phil










Path: ucivax!gateway
From: [e-mail] (Ephraim Vishniac)
Subject: Re: Think-C v5.0 in MacWAREHOUSE ad.
Message-ID: <[e-mail]>
In-Reply-To: Your message of "27 Jul 91 01:29:11 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 27 Jul 91 22:46:30 GMT


   From: Phil Shapiro <[e-mail]>
   Date: 27 Jul 91 01:29:11 GMT

   Re: the MacWarehouse ad: The official line on this is that it was a
   media scheduling error.  As with any of our products, a new release
   will occur when and if a product is fully tested and is ready to be
   released, no sooner.

But if you had your druthers, I'll bet you'd rather that day was, oh,
August 6th.

Ephraim Vishniac    [e-mail]   [e-mail]
 Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142
        One of the flaws in the anarchic bopper society was
        the ease with which such crazed rumors could spread.










Path: ucivax!gateway
From: [e-mail]
Subject: [[e-mail]: Re: Think-C v5.0 in MacWAREHOUSE ad.]
Message-ID: <9107280108.AA14329@husc10>
Newsgroups: fa.think-c
Lines: 30
Date: 28 Jul 91 01:09:14 GMT

Here's a message that Povl sent to me instead of the think-c list.
I'm forwarding it to the list and to him at his request...

--Erik

Return-Receipt-To: [e-mail]
Date: Sun, 28 Jul 91 01:13 +0200
From: "Povl H. Pedersen" <[e-mail]>
Subject: Re: Think-C v5.0 in MacWAREHOUSE ad.
To: evensen@husc
X-Envelope-To: [e-mail]
X-Vms-To: UNIL63::IN%"[e-mail]"


I would also like the 5.0 to be a full C++, but from the romours there
has been over time, then the next major release (guess that is 5.0) will
be a full ANSI compiler, and not full C++.

This is the reason why I have ordered the MPW C bundle and C++ from APDA.
I need C++ to a larger programming project that I am part of, that will
be created for DOS machines, and then quickly after that ported to mac.
I program the general parts, and thge Mac I/F, and am thus making sure
that our code is very portable from the start. But I needed the C++.
So I will stick to slow MPW C/C++ until Symantec comes with a full C++.

SYMANTEC, THERE IS A MARKET OUT HERE! GIVE US WHAT WE DEMAND "!!!

Povl H. Pedersen,
[e-mail]   /   [e-mail]











Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: WindElephant
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 20
Date: 28 Jul 91 17:18:49 GMT
X-Phone: [phone] x115


From: Adam Schabtach <[e-mail]>
Subject: submission for archives
Date: Sun, 28 Jul 91 10:53:19 MDT

Hello--

The attached .sit/.hqx file contains an init (and accompanying
documentation) that fixes an often-complained-about problem with the
THINK C debugger. It remembers the positions and sizes of the main
windows in the debugger. Move the windows to where you want them once,
and they stay there until moved again.

I haven't used it much, but it seems to work. I didn't write it; I claim
no credit or responsibility for it. Just passing it on.

--Adam
[e-mail]

[saved as: /mac/think-c/compiler/windelephant.hqx; 11K]










Path: ucivax!gateway
From: [e-mail] (Russell Donnan)
Subject: Re:  Think-C v5.0 in MacWAREHOUSE ad.
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 29 Jul 91 12:31:41 GMT

>The MacWAREHOUSE ad in the newest MacWorld (Sep 91) shows Think C v5.0
>with a price of $209.  When I called, they said the computer was listing
>v4.0, but it was out of stock.  The girl on the other end said the
>ad lists 5.0 because that's what is expected to be shipped... in about
>1 1/2 weeks.

I find it awfully hard to believe that it is shipping in 1 1/2 weeks if
we, the loyal following, haven't received our upgrade notices.  On the other
hand, I never received an upgrade notice for ThinkC 4.0 or Think Pascal 3.0
either.  Has anyone received an upgrade anouncement for ThinkC 5.0?
It's not like I haven't faithfully upgraded every Revision since I bough
LightSpeed C v1.1 way back when...

-Russ
---
Russ Donnan, [phone], [e-mail]
Convex Computer Corporation, 3000 Waterview Parkway, Richardson, TX, USA
Vs lbh pna ernq guvf, guvax nobhg vg.  Lbh'er n areq zna...










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Help Me Understand Colour
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 72
Date: 29 Jul 91 15:39:26 GMT

It's like this. I'm a Mac user and programmer. I have a couple of volumes
of Inside Mac and the technotes stack, System 7.0, ResEdit 2.0.1, THINK C,
MIDI Manager, two hard disks, two monitors, and have written tens of
thousands of lines of code on my machine, but one thing now confuses me:

Colour.

I've read the Inside Mac V chapters on the Color and Pallette Managers and
scoured the tech notes, but somehow I don't feel I have the whole story.
Could somebody fill me in? Just to make it less work if you do wish to
follow up, I'll draw boxes for you to tick.

I have a Radius FPD with 2 bits' worth of greyscale (OK, not much in the
way of colour, but I prefer greyscale and I intend to add more bits). I'm
finding that programs and control panel windows tend to alter the "colours"
fairly indiscriminantly and leave them altered. When I first used the
monitor it was highlighting Finder icons in grey, and very nice it was too.
Now it highlights them in very dark (5% perhaps?) grey and I can't change
it back. Most of them time disabled menu items are a proper shade of grey,
but after opening a control panel or two the menus become stippled instead.
My guess is that the pallette manager is trying to deal with serious colour
contention, and things like the stippled menus and variable desktop
colouring are due to applications (and the Finder) being quite lax about
their colour requirements, so there is some hysteresis in the pallette
management. Am I right?

        Yes: [ ]   No: [ ]   It's not that simple: [ ] _____________

A more fundamental question: who decides what colours I have available
anyway? The pallette management is a relative thing, depending on the
lookup table in place, but where does that come from when I turn my machine
on?

        System File: [ ]   Video Card: [ ]   It's not that simple: [ ]
______

(I noticed a couple of clut resources in the system file, but nothing for
2-bit grey.)

Under System 7.0, the Finder is always running, so (presumably) it always
has a pallette in context. So, what about things like the desktop pattern?
I can open eight colour wheels from the General control panel, but I don't
see how this makes any sense since I only have two free levels of grey.
Opening a colour wheel has a nondeterministic, and temporary, effect. I
always get back to two fixed greys (5% or so and another which is the
highlighting shade: 60% or so). Should the desktop pattern/colour dialog
make sense to me? Even if I have a lot of "real" colours, whose pallette is
the desktop using? Is it really too complicated for me to understand?

        No: [ ] ____________   Yes: [ ]

Finally: can someone give me a brief explanation of icl4 and icl8
resources?

        Yes: [ ] ____________   No: [ ]

I'm assuming that they are purely for the Finder desktop icons (and form
part of BNDL resources). In this case, they must conform to the Finder's
pallette. Is this fixed? (i.e. are Finder icons drawn from a fixed set of
colours?) I assumed that icl4 resources were 4-bit (16-colour) and icl8
were 8-bit, but it doesn't seem to be that simple. ResEdit provides two
colour pallettes which overlap in some strange way, and I don't understand
the significance of this.

Sorry for all the questions, but Inside Mac V and the TN's don't seem to
provide any answers. I'm willing to be pointed at documentation. (Bear in
mind that I'm in Scotland so finding it might be difficult...)

Anybody who helps gets, as a free gift, a copy of my first icl4.

        Nick.











Path: ucivax!gateway
From: [e-mail] (Jamie McCarthy)
Subject: Re: Colo[u]r
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 96
Date: 29 Jul 91 18:27:57 GMT

Nick Rothwell writes:

> It's like this. I'm a Mac user and programmer. I have a couple of volumes
> of Inside Mac and the technotes stack, System 7.0, ResEdit 2.0.1, THINK C,
> MIDI Manager, two hard disks, two monitors, and have written tens of
> thousands of lines of code on my machine, but one thing now confuses me:
>
> Colour.

If I explain it to you, will you give me one of your monitors?

> I've read the Inside Mac V chapters on the Color and Pallette Managers

Speaking as someone who's written a game using the Color instead of the
Palette Manager:  skip the Color Manager chapter.  Read it for
background if you really want to, but don't use any of the routines in
there.  If I could do it over again, I'd use the Palette Manager; you
should too.

If you have a very pressing need, the C.M. can of course be useful--but
by the time you know if you have a pressing need, you'll understand
everything so well you'll ignore any advice I give you anyway.  :-)

> Most of them time disabled menu items are a proper shade of grey,
> but after opening a control panel or two the menus become stippled instead.
> My guess is that the pallette manager is trying to deal with serious colour
> contention, and things like the stippled menus and variable desktop
> colouring are due to applications (and the Finder) being quite lax about
> their colour requirements

In 2-bit color, you have black, white, 50% gray, and your chosen hilite
color (with the "Color" control panel).  I suspect it's the same in
2-bit gray.

If some application demands too many colors--"too many" being in your
case two--the menus can no longer be done in gray, and will be stippled.
("Stippled" is a good word to distinguish the two new kinds of
"graying-out"--I like it.)  So yes, "serious" color contention, but
it doesn't take much to make 2-bit gray monitors get serious.  If you
can play with a 256-color system, it may help a lot.

Most applications should make "pmTolerant" or "pmCourteous" demands for
color, and if the color they demand is acceptable to the Finder, it will
pmTolerantly demand the same color, and the Finder and Other App will
happily share.  Some applications (paint programs, games) will make
"pmExplicit" or "pmAnimated" demands, and the Finder won't be able to
use those colors.

> A more fundamental question: who decides what colours I have available
> anyway? The pallette management is a relative thing, depending on the
> lookup table in place, but where does that come from when I turn my machine
> on?

The "default" palettes are stored as 'pltt' resources equal to screen
depth, plus 128 (I think) for greyscale.  So 2-bit gray is (someone
double-check me here) the ROM 'pltt' resource ID 130.

> Finally: can someone give me a brief explanation of icl4 and icl8
> resources?
>
>         Yes: [ ] ____________   No: [ ]
>
> I'm assuming that they are purely for the Finder desktop icons (and form
> part of BNDL resources). In this case, they must conform to the Finder's
> pallette. Is this fixed? (i.e. are Finder icons drawn from a fixed set of
> colours?) I assumed that icl4 resources were 4-bit (16-colour) and icl8
> were 8-bit, but it doesn't seem to be that simple. ResEdit provides two
> colour pallettes which overlap in some strange way, and I don't understand
> the significance of this.

They _should_ conform to the Finder's palettes.  There're something like
31 "recommended" Finder colors out of the possible 256 colors that an
'icl8' can use.  ResEdit will show you both of these palettes.  If
you're designing an icl for your own use, use whatever colors you like,
but if it's for the Finder, you should stick to the 31 base colors.
Same for icl4, but fewer colors, naturally.

I don't know for sure, but I suspect the Finder demands these "base"
colors pmTolerant-ly, and the others pmCourteous-ly.

> Anybody who helps gets, as a free gift, a copy of my first icl4.
>
>         Nick.

I'd be overjoyed.

The main thing about color is to understand the structure of a 'pltt'
resource and a PaletteHandle;  to understand the different types of
color usage (all six);  to understand attaching palettes to windows, and
when palettes get changed, and how updates get sent when they do;  and
to understand how GDevices fit in to everything.  There's more but
that's the main stuff.  I'm a long ways from being an expert, but I'm
trying...
--
 Jamie McCarthy                    [e-mail]
 Disclaimer:  it's my responsibility iff they're my words.










Path: ucivax!gateway
From: [e-mail] (Francis Taylor)
Subject: Berkeley Sockets for Think C
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 4
Date: 29 Jul 91 19:34:52 GMT

Does anyone have an implementation of Berkeley Sockets for MacTCP and
Think C?  There was something mentioned in comp.sys.mac.programmer a
while back, but the machine and the author have both disappeared.
Thanks.










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Re: Colo[u]r
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 92
Date: 30 Jul 91 13:49:54 GMT

>If I explain it to you, will you give me one of your monitors?

heh, well, I'd like to hang onto the Radius FPD (at least until I've paid
for it) and the other is the SE/30 internal which won't really detach
without surgery. Anyways, thanks for your comments, and also to Phil
Shapiro (some of whose comments I might refer to) and Chris Johnson.

>Speaking as someone who's written a game using the Color instead of the
>Palette Manager:  skip the Color Manager chapter.

Fair enough. I can see that the Pallette Manager provides everything I
should need in an application, but I was curious where the initial colours
came from in the first place. Phil tells me it's the video card, although
there are clut resources in the System file as well, so I'm not totally
clear what part they both play. I also notice (explicit) colour tables
mentioned in the Control Manager chapter of IM-V as well, which is a bit
confusing. Controls should be drawn in a window with a pallette; I don't
see why *anything* should be pottering around with RBG values (except those
specified in pallettes). I also notice that... (flip flip flip...) "Each
colour window... should have its own colour table" (V-204) - I presume that
this is a set of specific colours for the WDEF, giving title bar colours
and the like. I don't see why this isn't a pallette instead.

>In 2-bit color, you have black, white, 50% gray, and your chosen hilite
>color (with the "Color" control panel).  I suspect it's the same in
>2-bit gray.

Actually, I seem to have black, white, *5% grey* and my highlight colour.
The 5% grey is what the Finder uses to highlight icons (as opposed to the
highlight colour for text) which isn't too pretty. Now, I suspect my
troubles are caused by the General control panel and the colour wheels used
for setting the desktop pattern. Phil reckons it doesn't make any sense to
have eight colour wheels for a 2-bit system, and I tend to agree. It's
these things which seem to make permanent (and confusing) changes.

>If some application demands too many colors--"too many" being in your
>case two--the menus can no longer be done in gray, and will be stippled.
>("Stippled" is a good word to distinguish the two new kinds of
>"graying-out"--I like it.)

...and there's another (small) piece to the puzzle here - various system
components (menus, and controls such as buttons) seem able to sense when
there is a 50% grey they can use for disabled items, and will stipple if
they can't find it. I expect there is a simple way to do this, but I didn't
notice it on a first pass through the documentation. It would be a useful
trick to know - I do stippling in my application even when I have that grey
available.

>Most applications should make "pmTolerant" or "pmCourteous" demands for
>color, and if the color they demand is acceptable to the Finder, it will
>pmTolerantly demand the same color, and the Finder and Other App will
>happily share.

OK, now hang on a second... (flip flip flip...) pmTolerant I understand
(and precise matches have tolerance 0) but I don't understand the
definition of pmCourteous on page V-154. What is a courteous colour?

>The "default" palettes are stored as 'pltt' resources equal to screen
>depth, plus 128 (I think) for greyscale.  So 2-bit gray is (someone
>double-check me here) the ROM 'pltt' resource ID 130.

OK, I'll have to double-check. I think my System file contains two
pallettes, one for 4-bit and one for 8-bit colour, and nothing else. Phil
tells me that the "default pallette" is loaded from the video card and is
the one used by the Finder (so the Finder's window appearance is dependent
on the video card's colour table. Hmm...)

>but if it's for the Finder, you should stick to the 31 base colors.
>Same for icl4, but fewer colors, naturally.

Fine. I was a little confused by ResEdit's interface to the icl4/icl8
editor, but I noticed that the pallette was constant so ResEdit is
presumably using the "default" System pallette in order to show me what the
Finder will display.

Anyway. There seems to be more information in the Window Manager chapter of
IM-V, so I'm going to dig into that next. My immediate problem is to get
back the grey icon highlighting in the Finder (highlighting in something
close to black is no fun). I can't do much more until I add some more pixel
depth; I'm assuming that the Finder 7.0 interface engages its warp drive
once I have 4-bit greyscale or above.

Thanks again for the information. If/when things become clear to me, I'll
post another message. I'm still surprised that it's all so complicated,
though. I almost wish it was just a case of painting everything bright blue
and purple like IBM PC's do. Well, on second thoughts...

        Nick.

P.S. Regarding the European/American spellings: it seems to be quite
simple. I just let the *Color* Manager manage my *Colours*.











Path: ucivax!orion.oac.uci.edu!nntpsrv
From: [e-mail] (Bill Dugan)
Subject: QK cache needed with QuicKeys 2.1?
Nntp-Posting-Host: teri.bio.uci.edu
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Organization: University of California, Irvine
Lines: 7
Date: 30 Jul 91 14:21:09 GMT
Distribution: na

The title sums it up.  With Quickeys 2.1 and System 7.0, am I still
supposed to use the QK cache init?

bill
--
bill
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Daniel LaLiberte)
Subject: Re: Colo[u]r
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 30 Jul 91 15:15:24 GMT

I wrote a clut editor, that happens to be called NCSA PalEdit, which
does direct clut manipulation.  You may find it interesting to look over
the source which is available via anonymous ftp from ftp.ncsa.uiuc.edu.
This was written with Think C by the way.

Dan LaLiberte
National Center for Supercomputing Applications
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: QK cache needed with QuicKeys 2.1?
Message-ID: <[e-mail]>
In-Reply-To: Bill Dugan's message of 30 Jul 91 14:21:09 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 30 Jul 91 17:09:49 GMT

From: Bill Dugan <[e-mail]>
   The title sums it up.  With Quickeys 2.1 and System 7.0, am I still
   supposed to use the QK cache init?

No, the QK cache is no longer necessary (starting with QK 2.0, I
think).

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Adam Schabtach)
Subject: Default Palette
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 31 Jul 91 03:35:08 GMT

All this talk about colors has reminded me of a question I've had for
a long time: how were the colors for the default 8-bit palette chosen?
Was there any logic to it? If you look at the default palette, there
seems to be little sense to the way it's organized, a fair amount of
redundancy, and a number of missing colors (a good orange, for
instance).

Anybody happen to know why it's set up this way?

I have discovered something that might explain it, but I sort of hope
I'm wrong. Remember the old GIF of the mirrored balls suspended in
space above an infinite plane of Apple logos? I think Apple used to
use it to show off the Mac II, and SuperMac used it in advertisements
for their monitors. The CLUT for that GIF seems to be the same as the
default palette. Now, Apple wouldn't just arbitrarily use that CLUT as
the default palette for no other good reason, would they? Tell me it
ain't so...

--Adam











Path: ucivax!gateway
From: [e-mail] ("Matthew T. Russotto")
Subject: Re:  Default Palette
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 31 Jul 91 13:56:00 GMT

Take a look at the default CLUT.  There is a definite pattern to it:
Blue = ($F - ((index mod 6)*3)) * $1111
Green = ($F - (((index div 6) mod 6)*3)) * $1111
Red = ($F - (((index div 36) mod 6)*3)) * $1111

This continues until index $D6.  At index $D7, all the missing pure reds
appear, followed by all the missing pure greens, followed by all the missing
pure blues, followed by all the missing greys.










Path: ucivax!gateway
From: [e-mail] (opcode ranger)
Subject: Some (weenie?) AppleEvent questions
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 85
Date: 31 Jul 91 19:51:56 GMT
X-Vmsmail-To: @THINKC

I have some basic questions regarding AppleEvents.  I found the IM VI
documentation basically pretty good (and a great improvement over previous
volumes), but sometimes a little vague.  I realize that some of these questions
may be dumb, but any help is much appreciated!  (If the answers can be found in
a doc -- IM, TechNote, sample code -- please let me know).

1) I understand how to check to see if you missed any required parameters when
you're handling a received AppleEvent (although you could use
AEGetAttributeDesc() instead of AEGetAttributePtr() when checking for the
keyMissedKeywordAttr, right?  All you're checking for is that it doesn't exist,
right?).

Anyway, how does the AppleEvent manager know which the required parameters are?
Something to do with the keyOptionalKeywordAttr, right?  But how does this work
exactly?

2) When you dispose of an AppleEvent with AEDisposeDesc(), does this dispose of
the descriptor records of all the contained parameters and attributes too?  I
would assume so, but the comments to the code on IM VI p. 6-61 made me wonder:
"be sure to dispose of the event and first parameter before leaving routine".
It seems to imply that these are two separate things to do.

3) The handling of timing out confuses me.  In the example code in IM VI, it
would seem that if the AESend() times out, one simply punts.  But on page 6-64,
there is extensive discussion about how if AESend() times out, it doesn't mean
that the server app will not return a reply.  In particular, I can't entirely
figure out:

" If the server finishes processing the Apple event sometime after the time
specified in the timeout parameter has expired, it returns a reply Apple event
to AEProcessAppleEvent.  The Apple Event Manager then returns the reply to the
client in the reply parameter that the client originally passed to the AESend
function....This means your application can continue to check the reply Apple
event to see if the server has responded, even after the time expires."

Now, in the sample code in Listing 6-17 in IM VI, it seems to me that the reply
record passed to AESend() may be out of scope by the time the server finishes
processing the AppleEvent, so how can it return "the rpely to the client in the
reply parameter that the client originally passed to the AESend function"?

That is, if AESend() times out, and the function MySendMultiplyEvent() returns,
what's going to happen when the server app finally gets thru processing?

And along that line, can you dispose of the reply you passed to AESend() before
the server has finished processing?

Obviously I'm missing something.  Can someone show me some sample code which
implements the checking-routine as described in the time-out discussion on p.
6-64?

4) Here's a really dumb one: what exactly are "OS Events" as defined for the
idle procs you can write for the AE manager (that is, what kinds of events fall
into the category "OS Event")?

5. What is the difference between the "key" get/put data functions and the
"param/attribute" get/put data functions?  For example, what is the difference
between AEGetKeyPtr() and AEGetParamPtr()?  Are the "param/attribute" versions
of these get/put functions -- in both their "Ptr" and "Desc" variants --
basically just the same thing as the "key" functions?  On that line, why is
there an AEDeleteKeyDesc() function and an AEDeleteParam() function , but no
'AEDeleteAttribute()' function?

6. In numerous descriptions of 'creation' functions you find the phrase "This
function creates a new descriptor record by copying the descriptor record from
the parameter" (for instance in AECreateList(), IM VI p.6-88).  What does this
mean exactly?  In these functions does one have to pass a descriptor record and
get back a copy?   For instance, does one have to pass an already created
DescList to AECreateList() and receive back a copy?


Thanks for any help!

Robert

============================================================================
= [e-mail] * generic disclaimer: * "Out there on a   =
=                             * all my opinions are *  darkened road,   =
=                                * mine                *  the lights are   =
=                 *               *  dead and the     =
=                 *               *  cars explode."   =
=                 *               *  -- "Good Things",=
=                 *               *  Sisters of       =
=                 *               *  Mercy           =
============================================================================











Path: ucivax!gateway
From: [e-mail] ("Mr. Neb")
Subject: Threads...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 9
Date: 31 Jul 91 23:46:11 GMT


    I got some code from the last Develop CD dealing with threads on
the Mac.  It looks really interresting, but I don't have MPW C++... has
anyone converted this to Think-C?  If so, I would like to know what and
how you did it (or possibly the modified code.)

    Thanks in advance,
    David Nebinger
    [e-mail]